Bug#726655: [PATCH] floppy: Correct documentation of driver options when used as a module.
On Fri, 18 Oct 2013, Ben Harris wrote: From: Ben Harris bj...@cam.ac.uk The options have to be passed space-separated and prefixed by floppy=, rather than separately and unprefixed. Applied, thanks. -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1311060937380@pobox.suse.cz
Bug#694546: HID: Add Apple wireless keyboard 2011 ANSI to special driver list
On Sun, 2 Dec 2012, Ben Hutchings wrote:
Commit 0a97e1e9f9a6 ('HID: apple: Add Apple wireless keyboard 2011 ANSI PID')
did not update the special driver list in hid-core.c, so hid-generic may
still bind to this device.
Reported-by: Ari Pollak a...@scvngr.com
References: http://bugs.debian.org/694546
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Thanks for the fix, appiled.
--
Jiri Kosina
SUSE Labs
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/alpine.lnx.2.00.1212022108580.27...@pobox.suse.cz
Bug#685360: [PATCH 1/1] HID: Fix missing Unifying device issue
On Fri, 21 Sep 2012, Nestor Lopez Casado wrote: This patch fixes an issue introduced after commit 4ea5454203d991ec After that commit, hid-core silently discards any incoming packet that arrives while any hid driver's probe function is being executed. This broke the enumeration process of hid-logitech-dj, that must receive control packets in-band with the mouse and keyboard packets. Discarding mouse or keyboard data at the very begining is usually fine, but it is not the case for control packets. This patch forces a re-enumeration of the paired devices when a packet arrives that comes from an unknown device. Based on a patch originally written by Benjamin Tissoires. Signed-off-by: Nestor Lopez Casado nlopezca...@logitech.com I am now applying it, will be pushing to Linus very soon, and am also marking it for stable 3.2+ Thanks to everyone involved. -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1209220949380.32...@pobox.suse.cz
Bug#685360: [PATCH 1/1] HID: Fix missing Unifying device issue
On Sat, 22 Sep 2012, Jiri Kosina wrote: This patch fixes an issue introduced after commit 4ea5454203d991ec After that commit, hid-core silently discards any incoming packet that arrives while any hid driver's probe function is being executed. This broke the enumeration process of hid-logitech-dj, that must receive control packets in-band with the mouse and keyboard packets. Discarding mouse or keyboard data at the very begining is usually fine, but it is not the case for control packets. This patch forces a re-enumeration of the paired devices when a packet arrives that comes from an unknown device. Based on a patch originally written by Benjamin Tissoires. Signed-off-by: Nestor Lopez Casado nlopezca...@logitech.com I am now applying it, will be pushing to Linus very soon Now in Linus' tree and marked for stable. Thanks, -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.120946320.32...@pobox.suse.cz
Bug#685360: Logitech USB keyboard broken with Linux 3.2 (regression from 3.1)
On Tue, 18 Sep 2012, Nestor Lopez Casado wrote: Hello Josip, I am back at the office. Please let me know if applying the patch solved your problem. Yes, please let me know. I'd like to have confirmation so that we could have it for 3.6 still (otherwise we'll go with -stable of course). I'll of course need the patch from [1] with proper commit message and sign off. Adding Benjamin to CC. [1] https://bugs.launchpad.net/ubuntu/+bug/958174/comments/55 -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1209191533290.31...@pobox.suse.cz
Re: [RFC] Simplifying kernel configuration for distro issues
On Fri, 13 Jul 2012, Linus Torvalds wrote: So this has long been one of my pet configuration peeves: as a user I am perfectly happy answering the questions about what kinds of hardware I want the kernel to support (I kind of know that), but many of the support infrastructure questions are very opaque, and I have no idea which of the them any particular distribution actually depends on. And it tends to change over time. For example, F14 (iirc) started using TMPFS and TMPFS_POSIX_ACL/XATTR for /dev. And starting in F16, the initrd setup requires DEVTMPFS and DEVTMPFS_MOUNT. There's been several times when I started with my old minimal config, and the resulting kernel would boot, but something wouldn't quite work right, and it can be very subtle indeed. Similarly, the distro ends up having very particular requirements for exactly *which* security models it uses and needs, and they tend to change over time. And now with systemd, CGROUPS suddenly aren't just esoteric things that no normal person would want to use, but are used for basic infrastructure. And I remember being surprised by OpenSUSE suddenly needing the RAW table support for netfilter, because it had a NOTRACK rule or something. The point I'm slowly getting to is that I would actually love to have *distro* Kconfig-files, where the distribution would be able to say These are the minimums I *require* to work. So we'd have a Distro submenu, where you could pick the distro(s) you use, and then pick which release, and we'd have something like I agree that this would be very nice to have exactly for the reasons you have pointed out. [ ... snip ... ] and then depending on the DISTRO config, we'd include one of the distro-specific ones with lists of supported distro versions and then the random config settings for that version: - distro/Kconfig.suse: config OPENSUSE_121 select OPENSUSE_11 select IP_NF_RAW # .. - distro/Kconfig.Fedora: config FEDORA_16 select FEDORA_15 select DEVTMPFS # F16 initrd needs this select DEVTMPFS_MOUNT # .. and expects the kernel to mount DEVTMPFS automatically ... config FEDORA_17 select FEDORA_16 select CGROUP_xyzzy ... and the point would be that it would make it much easier for a normal user (and quite frankly, I want to put myself in that group too) to make a kernel config that just works. But we'll first have to make 'select' to actually work, right? It currently doesn't resolve the dependencies of the selected configs, so it will just produce some very broken config. -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.00.1207201145310.16...@twin.jikos.cz
Bug#675093: linux-image-3.2.0-2-amd64: USB timeout initializing reports with Eaton UPS
On Thu, 31 May 2012, Manu Benoît wrote:
Alright, got the log you requested.
Ok, thanks. I will have to think about this whole thing a little bit more,
but as a first step, could you please try with the patch below to see if
it makes any difference and makes the device behave correctly? Thanks.
NOT-Signed-off-by: Jiri Kosina jkos...@suse.cz
---
drivers/hid/usbhid/hid-core.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 482f936..4da252d 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -367,6 +367,9 @@ static int hid_submit_ctrl(struct hid_device *hid)
} else {
int maxpacket, padlen;
+ if (hid-quirks HID_QUIRK_NOGET)
+ return;
+
usbhid-urbctrl-pipe = usb_rcvctrlpipe(hid_to_usb_dev(hid), 0);
maxpacket = usb_maxpacket(hid_to_usb_dev(hid),
usbhid-urbctrl-pipe, 0);
--
Jiri Kosina
SUSE Labs
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/alpine.lnx.2.00.1206081354470.12...@pobox.suse.cz
Bug#675093: linux-image-3.2.0-2-amd64: USB timeout initializing reports with Eaton UPS
On Thu, 31 May 2012, Ben Hutchings wrote:
Package: linux-2.6
Version: 3.2.18-1
Severity: normal
It would seem that the kernel is doing something wrong when trying to
initalise an USB connection to an Eaton (formerly Merlin Gerin) Ellipse
Max UPS.
When the box is booting, the device's initialisation adds a ~15s delay,
then some USB error is reported (at timestamp 18.319789 in the kernel
log below).
Strangely enough, the device appears to work after that.
I am reporting this error for the kernel on this computer (which is a
x86-64 and includes various tainted modules), however it also occurs on
a much older x86 box running a Debian Squeeze with
linux-image-2.6.32-5-686 (no proprietary drivers loaded, either). The
device connected to that box is a different model of Eaton Ellipse Max
UPS. Both UPS's are brand new.
[...]
[5.167483] usb 2-2.4: New USB device found, idVendor=0463,
idProduct=
[5.167488] usb 2-2.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[5.167491] usb 2-2.4: Product: Ellipse MAX
[5.167493] usb 2-2.4: Manufacturer: EATON
[5.167496] usb 2-2.4: SerialNumber: ADKM25014
[5.208346] usb 2-1.2: reset high-speed USB device number 6 using
ehci_hcd
[5.384134] usb 2-1.2: reset high-speed USB device number 6 using
ehci_hcd
[5.560072] usb 2-1.2: reset high-speed USB device number 6 using
ehci_hcd
[5.736015] usb 2-1.2: reset high-speed USB device number 6 using
ehci_hcd
[5.869976] PM: Starting manual resume from disk
[5.869979] PM: Hibernation image partition 254:1 present
[5.869980] PM: Looking for hibernation image.
[5.870175] PM: Image not found (code -22)
[5.870178] PM: Hibernation image not present or could not be loaded.
[5.910554] EXT4-fs (dm-0): mounted filesystem with ordered data
mode. Opts: (null)
[ 18.319789] generic-usb 0003:0463:.0003: usb_submit_urb(ctrl) failed
[ 18.319850] generic-usb 0003:0463:.0003: timeout initializing reports
[ 18.320070] generic-usb 0003:0463:.0003: hiddev0,hidraw2: USB HID
Hmm, that's odd. This device has been on 'HID_QUIRK_NOGET' list for very
long time already (even before 2.6.32). Could you please apply the patch
below, modprobe hid module with 'debug=1' parameter, and send me the
output?
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 482f936..25ebf54 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -397,6 +397,7 @@ static int hid_submit_ctrl(struct hid_device *hid)
r = usb_submit_urb(usbhid-urbctrl, GFP_ATOMIC);
if (r 0) {
hid_err(hid, usb_submit_urb(ctrl) failed: %d\n, r);
+ dump_stack();
return r;
}
usbhid-last_ctrl = jiffies;
--
Jiri Kosina
SUSE Labs
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/alpine.lnx.2.00.1205310950310.15...@pobox.suse.cz
Bug#671292: [PATCH/RFC v2] HID: logitech: read all 32 bits of report type bitfield
On Fri, 11 May 2012, Jonathan Nieder wrote: From: Nestor Lopez Casado nlopezca...@logitech.com On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine. That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears: 20 00 41 02 00 00 00 00 00 00 00 00 00 00 00 and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x0200 and is not recognized. Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason. Fix both problems by using get_unaligned_le32() to read all four bytes, which is a little clearer anyway. After this change, the wireless mouse works on Hugo's PowerBook again. Addresses http://bugs.debian.org/671292 [jn: with commit message and tweaked to use get_unaligned instead of copying onto the stack] Reported-by: Hugo Osvaldo Barrera h...@osvaldobarrera.com.ar Signed-off-by: Jonathan Nieder jrnie...@gmail.com If Nestor is really the original author of this patch, his Signed-off-by: is necessary. Nestor, please? Thanks, -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1205111254520.17...@pobox.suse.cz
Bug#671292: [PATCH v2 1/1] HID: logitech: read all 32 bits of report type bitfield
On Fri, 11 May 2012, Nestor Lopez Casado wrote: From: Jonathan Nieder jrnie...@gmail.com On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine. That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears: 20 00 41 02 00 00 00 00 00 00 00 00 00 00 00 and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x0200 and is not recognized. Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason. Applied, thanks. -- Jiri Kosina SUSE Labs -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1205111631590.17...@pobox.suse.cz
Bug#594089: keyboard-configuration: caps lock keycode problem
On Wed, 27 Oct 2010, Dmitry Torokhov wrote: First of all, the device appears to use duplicate usages for CapsLock/Favorites and RightShift/Previous so we better set up the duplicate usages quirk. I wonder how the other OS copes with diferent keys using the same usages. Jiri, any ideas? That thing I have been also wondering about when introducing the quirk for duplicate usages, but I haven't really found out. It's a bit odd. -- Jiri Kosina SUSE Labs, Novell Inc. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1010291054410.6...@pobox.suse.cz
