On Sat, 23 Jan 2021 18:21:36 -0600
Jeremy Figgins wrote:
> Signed-off-by: Jeremy Figgins
> +++ b/drivers/usb/class/usblp.c
> + if (usblp->intf->num_altsetting > 1) {
Acked-by: Pete Zaitcev
I am having some misgivings about it, but let's see if it works.
At worst
On Wed, 06 May 2020 11:14:42 +0200
Oliver Neukum wrote:
> Very well. We are not going to find it without exceptional luck. Yet
> there may be a real issue, too. We simply do not know. How about the
> attached patch?
> usblp_unlink_urbs(usblp);
> mutex_unlock(&usblp->mut);
> + usb
hat mutex_lock_interruptible()
can set the state, or it didn't do it back then (it was in 2007), and
the 7f477358e introduced the existing code.
Acked-By: Pete Zaitcev
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
On Tue, 05 May 2015 11:24:16 +0200
Arnd Bergmann wrote:
> On Tuesday 05 May 2015 11:44:33 Tina Ruchandani wrote:
> > static inline unsigned int mon_get_timestamp(void)
> > {
> > - struct timeval tval;
> > + struct timespec64 now;
> > unsigned int stamp;
> >
> > - do_gettimeofday(&t
On Thu, 14 Nov 2013 12:09:21 -0500
Chris Metcalf wrote:
> - __u8 buffer[CN_PROC_MSG_SIZE];
> + __u8 buffer[CN_PROC_MSG_SIZE] __aligned(8);
> - msg = (struct cn_msg *)buffer;
> + msg = buffer_to_cn_msg(buffer);
> ev = (struct proc_event *)msg->data;
> memset(&ev->event
On Wed, 20 Feb 2008 07:57:23 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> > that you did, after taking care of detection and initialization.
> > Look at his dmesg in comment #44 in this:
>
> Yes, that looks very similar.
Someone reported on the bug that a firmware update exists to resolv
On Fri, 16 Nov 2007 14:22:56 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> > > The difference with huaweiAktBbo.c seems that kernel uses a nonzero
> > > length.
> > > Can you try zero length with the kernel? It's the second argument to the
> > > last.
> >
> > I tried with the git patch p
On Tue, 12 Feb 2008 10:46:12 +0900, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On a serious note, it seems that two scatter lists per request leaded
> to this bug. Can the scatter list in struct ub_request be removed?
Good question. It's an eyesore to be sure. The duplication exists
for the sak
t's just Tomo or Jens made a mistake when converting to
the new s/g API. Nothing to be too concerned about. I know I should've
reviewed their patch closer, but it seemed too simple...
-- Pete
Fix up the conversion to sg_init_table().
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED
On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Looks like you deadlocked in ub_request_fn(). I assume that you were using
> ub.c in 2.6.23 and that it worked OK? If so, we broke it, possibly via
> changes to the core block layer.
>
> I think ub.c is basically aban
On Sun, 23 Dec 2007 08:46:37 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:
> I noticed you also have a spinlock held in usu_probe_thread(), the
> usu_lock.. That spinlock would preclude anything inside request_module()
> from sleeping..
The usu_lock is not held across request_module. In fact, i
On Sat, 22 Dec 2007 09:01:50 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:
> Then in usu_probe_thread() your basically stopping it at the start of
> the function with a down(), and the up() is just ancillary .. So you
> could easily move the up() further down in the function and still have
> the
On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote:
> I converted the usu_init_notify semaphore to normal mutex usage, and it
> should still prevent the request_module before the init routine is
> complete. Before it acted more like a complete, now the mutex protects
> tw
On Fri, 14 Dec 2007 12:04:54 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]>
wrote:
> I have investigated all code paths which call ub_end_rq() in ub.c,
> and confirmed that ub_end_rq() is always called with the queue lock
> held. (sc->lock is registered as a queue lock.)
Thanks for reminding me
On Wed, 12 Dec 2007 15:38:15 -0500 (EST), Kiyoshi Ueda <[EMAIL PROTECTED]>
wrote:
> On Tue, 11 Dec 2007 15:48:03 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > > - end_that_request_first(rq, uptodate, rq->hard_nr_sectors);
> > > - end_that_re
rq->errors = scsi_status;
> }
> - end_that_request_first(rq, uptodate, rq->hard_nr_sectors);
> - end_that_request_last(rq, uptodate);
> + if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
> + BUG();
Acked-by: Pete Zaitcev <[EMAIL PROTECTED]>
On Wed, 5 Dec 2007 19:23:14 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:
> > Looks good to me, shorter than my patch, has no duplication, allows to
> > use the storage, looks like a winner. Unfortunately,
n tests to see how it works. I'll collect any failing pieces later
if any.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
use the storage, looks like a winner. Unfortunately, it leaves ub for dead,
because ub cannot invoke the necessary initializer unless we move it to
libusual. But oh well, I'll think about it.
Took me this long to test because I had to ask kind people in England
to replug the modem.
Signed-off
On Sat, 1 Dec 2007 09:07:38 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> is this the only addition that should be needed, ortogether with the
> changes in option to call the huawei init function?
The only one.
> I tried 2.6.24-rc3 with this patch only and it I again got the infinite
> lo
On Thu, 29 Nov 2007 09:04:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > Isn't it possible to fix this in option's module table?
> >
> > At first thought it'll need adding a field to struct usb_serial to save
> > the driver_info from the ID table in usb_serial_probe. It's something I'd
>
On Thu, 29 Nov 2007 08:44:38 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> 3. Make sure usbcore doesn't probe the devices in the wrong mode with the
> option driver
This fixes duplication. And to take it further, why don't we turn this
idea around and let usb-storage fail to attach with some
On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > The problem stems from the fact that both option and usb-storage can bind
> > to the modem when in storage mode: the former
Hi, All:
It looks like the Huawei E220 saga is not over yet. A collegue of mine,
David Russll, reported that the modem does not work reliably on Fedora 8,
which does have the initializer in usb-storage.
The problem stems from the fact that both option and usb-storage can bind
to the modem when in
On Mon, 19 Nov 2007 15:22:11 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
This looks good, but have a couple of comments. Maybe I can fix it up.
> * we do not know how to support. We ignore them for the moment.
> * XXX Rate-limit the error message,
On Thu, 01 Nov 2007 11:06:24 +0200, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> > Do you still want to go ahead with a 2.4 backport?
>
> Yep. Will do it asap. In latest 2.4 patch we had just a locks issue.
> So do you think I should modify 2.4 patch with all modifications we done in
> 2.6 versio
se of
usb_kill_urb was outright racy (it unlinked and immediately freed).
- Fix indentation in adu_write. Looks like it was damaged by a script.
- Vitaly wants -EBUSY on multiply opens.
- bInterval was taken from a wrong endpoint.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-
On Wed, 31 Oct 2007 13:54:54 +0200, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-10-30 at 23:54, Pete Zaitcev wrote:
>
> > One other small thing. I see you dropped the dev->mtx bracket that
> > I added around the initialization and submission. Notice that
On Wed, 31 Oct 2007 07:23:56 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> Hmm, in addition I added a
> printk(KERN_ERR "ENTERING usb_stor_huawei_e220_init!\n");
> at the beginning of the function but it never showed up in my log files.
> So it seems that the UNUSUAL_DEV entry does no
On Tue, 30 Oct 2007 22:22:13 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> I tried the attached patch which I found on the usb list, but it didn't
> work, the cdrom was still always found, and it was
> connected/disconnected permanently.
The difference with huaweiAktBbo.c seems that kernel
On Tue, 30 Oct 2007 20:09:45 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> Is this a regression from 2.6.20, or is it supposed to work?
Please post your /proc/bus/usb/devices. Maybe it just fails to match.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Tue, 30 Oct 2007 15:09:54 +0200, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> As about read_urb_finished probably it's OK. But we shouldn't decrease
> open_count in the case of error as then we return normal exit value.
Oh, thanks. I fixed that.
One other small thing. I see you dropped the dev
On Mon, 29 Oct 2007 20:04:57 +0200, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> Finally had a time on my weekend to perform tests and fix Pete's patch a
> little. Now it seems to be correct.
Great!
> 1. One device per user space application. Old driver allowed many users
> application to work
On Thu, 25 Oct 2007 14:03:48 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag 25 Oktober 2007 schrieb Pete Zaitcev:
> > + if (signal_pending(current)) {
> > dbg(1," %s :
BTW, the patch in my previous message had one buglet - an extra
remove_wait_queue. It was in an error case though, so it should be
ok to test. But just in case, here's a fixed one.
-- Pete
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index c567aa7..6914c0b 100644
--- a/drive
On Wed, 24 Oct 2007 17:09:47 +0300, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> > static void adu_abort_transfers(struct adu_device *dev)
> > {
> ...
> > + mutex_lock(&dev->mtx);
> ...
> > + mutex_unlock(&dev->mtx);
>
> > }
>
> Don't you think it's needed? You call adu_abort_transfers fr
se of
usb_kill_urb was outright racy (it unlinked and immediately freed).
- Fix indentation in adu_write. Looks like it was damaged by a script.
- Remove sleep_on.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
Oliver, thanks for the inftdata catch. I also fixed the sleep_on.
But I lef
On Tue, 23 Oct 2007 11:38:37 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > + /* XXX Anchor these instead */
> > + spin_lock_irqsave(&dev->buflock, flags);
> > + if (!dev->read_urb_finished) {
> > + spin_unlock_irqrestore(&dev->buflock, flags);
> > + usb_kill_urb(dev
On Fri, 19 Oct 2007 20:40:35 +0300, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
Hi, Vitaly, I added you on cc: for the 2.6 cleanup. Please double-check
what I'm doing there and use it for your 2.4 version. I hope my intentions
get clearer with an example. Now, about the specific question:
> Static
se of
usb_kill_urb was outright racy (it unlinked and immediately freed).
- Fix indentation in adu_write. Looks like it was damaged by a script.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
If someone with a real device tested this, it would be great. Please
make sure to pull the
On Fri, 19 Oct 2007 18:26:35 +0300, "Vitaliy Ivanov" <[EMAIL PROTECTED]> wrote:
> Didn't here anything on this? What is our final decision here?
It's gotten worse, not better. Apparently, you aren't getting the
concept of protecting the open count with a static lock and my
explanations are just n
On Tue, 16 Oct 2007 17:41:38 +0200, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> OK, I have no objection, but please apply the fixes the le16 problem as
> suggested by Pete and Greg first. Also, you will probably receive more
> comments, and/or criticisms from further reviews. This is normal and
> e
On Tue, 16 Oct 2007 16:54:49 +0300, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote:
> Again, comments are welcomed.
It looks like you misunderstood why a static lock protects open counts.
This is done so you do not need to worry about in-structure lock which
can be freed together with the structure. Lo
On Sun, 14 Oct 2007 23:45:36 +0300, "Vitaliy Ivanov" <[EMAIL PROTECTED]> wrote:
> Also IMHO the more drivers are in the tree the more users will use it.
> Once it will be merged in the mainline then it will be backported to
> enterprise kernels and would gain wide usage.
At least in case of RHEL,
On Fri, 12 Oct 2007 14:57:28 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Should I be submitting my driver as a patch to linux.kernel or are Alan
> > or Greg going to push their changes?
>
> Please submit your patches to Greg and the USB development list.
> Greg has a directory on kernel.
On Sat, 15 Sep 2007 03:48:19 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > I have an error message with 2.6.23-rc6.
> > This did not happen with 2.6.22.
>
> Another one for Michal's dirt file.
No, I think it's the module ordering again.
> > 2.6.23-rc6 boot.msg extract ( hub/usb )
I wish
On Thu, 13 Sep 2007 09:43:13 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> So why not make the 64 sector limit be the default? Get rid of the quirk:
> we already allow people to override it in /sys if they really want to, but
> realistically, it's probably not going to make any diffe
Hi, Greg (and others):
I do not seem to be able to find an answer, sorry.
Do you happen to remember if this was fixed after 2.6.22.1:
localhost kernel: EIP is at make_class_name+0x27/0x7a
localhost kernel: [] class_device_del+0x97/0x119
localhost kernel: [] class_device_unregister+0x8/0x10
loca
I received two updates, and something jumped out:
On Sun, 12 Aug 2007 23:38:00 -0700, [EMAIL PROTECTED] wrote:
> +F: drivers/block/ub.c
On Sun, 12 Aug 2007 23:38:30 -0700, [EMAIL PROTECTED] wrote:
> +F: /drivers/usb/class/usblp.c
Why do some patterns start with a leading slash and others do
On Fri, 3 Aug 2007 15:45:32 -0400, Dave Jones <[EMAIL PROTECTED]> wrote:
> > > My experience suggests the opposite. Of the several I've tried so far,
> > > none have worked with usb suspend.
> >
> > All of mine work. I'm wondering if this has something to do with
> > a hub or motherboard...
On Fri, 03 Aug 2007 15:29:21 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > Well, we did - with hindsight it may not have been such a great plan :)
> > I believe that Fedora did as well, but have disabled it in an update
> > kernel.
>
> Yeah, autosuspend broke too many devices. Way too many
On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
>
> > Kernel developers are a diverser lot than you think ;-)
> > We don't enable autosuspend in drivers we can't test, except where
> > the lack of a kerne
Create arch/x86_64/vdso/.gitignore and put vdso.lds into it.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
Utterly trivial but for some reason missing. V.odd. I must be
misunderstanding how this works, but just in case here's patch.
--- linux-2.6.23-rc1/arch/x86_64/vdso
On Tue, 26 Jun 2007 13:52:41 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 06/26/2007 10:20 AM, Keith Chew wrote:
> [cc: linux-usb-devel]
>
> > We have been using a Zydas based WIFI drivers under kernel 2.6.16.18
> > with great success. Recently, when we upgraded to 2.6.20.1 (also
> > teste
Vojtech agreed to pass usblp over to me, so if you find bugs don't bug him.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-by: Vojtech Pavlik <[EMAIL PROTECTED]>
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3702,12 +3702,12 @@ L: [EMAIL PROTECTED]
W:
On Fri, 8 Jun 2007 11:32:32 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > and from drivers/usb/core/usb.c:
> >
> > /* format to disable USB on kernel command line is: nousb */
> > __module_param_call("", nousb, param_set_bool, param_get_bool, &nousb,
> > 0444);
> Pete added that back in Decem
On Wed, 30 May 2007 16:42:41 -0700, Roland Dreier <[EMAIL PROTECTED]> wrote:
> If I just see
>
> for (pos = list_entry((head)->next, typeof(*pos), member),
> n = list_entry(pos->member.next, typeof(*pos), member);
>&pos->member != (head);
>pos = n, n =
On Wed, 30 May 2007 16:14:01 -0700, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > The negative is the sheer number of helper functions in list.h. Personally,
> > I find it difficult to retain a working knowledge of them. Iterators are
> > particularly nasty that way. I'm thinking about dropping
On Thu, 31 May 2007 02:44:17 +0530, "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> > > - list_for_each(p, &sc->luns) {
> > > - lun = list_entry(p, struct ub_lun, link);
> > > + list_for_each_entry(lun, &sc->luns, link) {
> > This patch straddles the border of acceptable. The poi
On Wed, 30 May 2007 10:47:52 +0200, Matthias Kaehlcke <[EMAIL PROTECTED]> wrote:
> @@ -1608,8 +1605,7 @@ static void ub_reset_task(struct work_struct *work)
> spin_lock_irqsave(sc->lock, flags);
> sc->reset = 0;
> tasklet_schedule(&sc->tasklet);
> - list_for_each(p, &sc->luns
On Tue, 22 May 2007 00:57:56 +0200, Eric Sesterhenn / Snakebyte <[EMAIL
PROTECTED]> wrote:
> http://marc.info/?l=linux-kernel&m=115144559823592&w=2
Shows how much we care about floppy... It's going to be a year old soon.
> +++ linux-2.6/drivers/block/floppy.c 2007-05-22 00:54:18.0 +020
On Mon, 14 May 2007 14:44:49 -0700, Kevin Lloyd <[EMAIL PROTECTED]> wrote:
> + schedule_timeout_uninterruptible(delay_t*HZ);
> + retval = sierra_ms_change_mode(us, SWIMS_SET_MODE_Modem);
> + if (retval == -ETIMEDOUT || retval == -ETIME) {
> +
On Sun, 13 May 2007 20:57:25 +0100, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> Ok, I've tidied this up a little. [...]
Looks fine here... well, almost. Did you try rmmod (I don't even know if
it's applicable, sorry)? Usually, when schedule_work is involved, you want
to make sure that a schedule
On Sun, 13 May 2007 18:20:53 +0100, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> +static void atp_reinit(struct work_struct *work)
> +{
> + char data[8];
> + size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
> +ATP_GEYSER3_MODE_READ_REQUEST_ID,
> +
On Sun, 13 May 2007 13:39:48 +0800, David Woodhouse <[EMAIL PROTECTED]> wrote:
> Please don't use my work email address unless I _really_ need to be
> wearing my tinfoil hat when I read it.
I'll keep it in mind, sorry.
> But we'd be wrong -- just as you are. SPF is utterly moronic because it
> s
On Mon, 7 May 2007 22:23:11 +0100, Alan Cox <[EMAIL PROTECTED]> wrote:
> We had this discussion before. Kernel sources should use utf-8 for
> comments where neccessary. Many names cannot be correctly represented in
> US ascii, and mangling them is just plain rude.
I have to disagree here. It is u
On Tue, 08 May 2007 18:52:31 +0100, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-05-08 at 18:45 +0100, Maciej W. Rozycki wrote:
> > Well, my name has an acute above "o" and a dot above "z", but I do not
> > have such a high expectation as to have it correctly spelled in comments
>
On Thu, 10 May 2007 15:35:56 +0200, "Joerg Roedel" <[EMAIL PROTECTED]> wrote:
> I debugged this problem a bit and my compiler[1]interprets the =A
> constraint as %rax instead of %edx:%eax on x86_64 which causes the
> problem. The appended patch provides a workaround for this and fixed the
> hang o
Hi, Andi:
The attached patch (actually, git show output) makes my Dell 1501 to hang
on boot. Sorry, I have no clue why... The culprit is found with git bisect.
But yes, it's an AMD MK-36. I use an x86_64 kernel. It is 100% reproducible.
Cheers,
-- Pete
commit c5bcb5635a03da3158f121ae20ccbbf72b4f
On Sat, 14 Apr 2007 09:14:25 -0400 (EDT), "Jeremy C. Andrus" <[EMAIL
PROTECTED]> wrote:
> On Fri, April 13, 2007 22:16, Pete Zaitcev wrote:
> > The transfer size in the URB is not limited by the maximum packet
> > size. The HC driver splits up the transfer a
On Fri, 13 Apr 2007 12:56:47 -0400, "Jeremy C. Andrus" <[EMAIL PROTECTED]>
wrote:
> I recently ran into a couple of USB devices which insisted on using 1024
> byte packets in bulk transfer mode (despite the hard limit of 512
> established in the spec). I really wanted to use these devices, so I
Hi, Peter:
There's one thing I wanted to report, just in case... It does not affect
anything, but it's odd.
Every time I lift a finger from the pad, the driver sends an event with
odd values (X is 1 and Y is 5855):
Event: time 1174695694.561806, type 1 (Key), code 330 (Touch), value 0
Event: tim
On Thu, 5 Apr 2007 16:54:17 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> > On a certain keyboard, when BIOS sets NumLock LED on, it survives the
> > takeover
> > by Linux and thus confuses users.
> >
> > Eating of an increasibly scarce quirk bit is unfortunate. We do it for
> > safety,
On a certain keyboard, when BIOS sets NumLock LED on, it survives the takeover
by Linux and thus confuses users.
Eating of an increasibly scarce quirk bit is unfortunate. We do it for safety,
given the history of nervous input devices which crash if anything unusual
happens.
Signed-off-by: Pete
On Tue, 03 Apr 2007 08:22:28 -0700, "Kok, Auke" <[EMAIL PROTECTED]> wrote:
> Having the gspca driver move into the main tree would help a lot though.
I think we need to articulate better why this is an issue and not just
an excuse. We know that scheduling issues with ISO transfers exist, but
with
On Tue, 3 Apr 2007 01:04:05 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> What do you think?
The patch looks sane, although I haven't yet tested it. I'll live with
it until next quarterly update, then consider if I should take it or use
my patch for RHEL 5 and RHEL 4.
-- Pete
-
To unsubscr
On Mon, 2 Apr 2007 16:48:24 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Sun, 1 Apr 2007, Pete Zaitcev wrote:
> could you please change the order of the two functions, so that you
> don't have to put the forward declaration here?
>[...]
> I'd say thi
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]>
wrote:
> I think I see an issue here. Imagine that you boot a system initially with
> one keyboard connected (usb, ps/2, doesn't matter), and after some time
> you connect second USB keyboard (the NumLock is 'on' on the
On Sun, 1 Apr 2007 14:49:59 +0300, "Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> On 3/30/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Dell people (Stuart and Charles) complained that on some USB keyboards,
> > if BIOS enables NumLock, it stays on even after L
On Sat, 31 Mar 2007 21:35:19 +0200 (CEST), Jiri Kosina <[EMAIL PROTECTED]>
wrote:
> On Fri, 30 Mar 2007, Pete Zaitcev wrote:
> I think I see an issue here. Imagine that you boot a system initially with
> one keyboard connected (usb, ps/2, doesn't matter), and after some
On Fri, 30 Mar 2007 14:14:20 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> > I didn't like a) layering violation, and b) that they defeat filtering
> > unconditionally. Why have any filtering then?
> >
> > Instead, I propose for USB HID driver to reset NumLock on probe. Like this:
> >
> >
This is a patch for comments only, please do not apply (at least not as-is).
I haven't got the test results yet.
Dell people (Stuart and Charles) complained that on some USB keyboards,
if BIOS enables NumLock, it stays on even after Linux has started. Since
we always start with NumLock off, this c
On Wed, 28 Mar 2007 20:00:32 +0400, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> result = usb_register(&ftdi_elan_driver);
> -if (result)
> +if (result) {
> + destroy_workqueue(status_queue);
> + destroy_workqueue(command_queue);
> + des
it's going to send an "add" right
> after. Instead it should enumerate the bus on resume and only send the events
> that represents how to get from the previous device tree to the current one.
> From Pete Zaitcev
> What does happen if a user suspends, unplugs a USB key,
On Tue, 27 Mar 2007 19:14:05 +0400, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> --- a/drivers/usb/misc/ftdi-elan.c
> @@ -2903,7 +2903,7 @@ static struct usb_driver ftdi_elan_driver = {
> };
> static int __init ftdi_elan_init(void)
> {
> -int result;
> +int result = 0;
Why do y
On Sun, 25 Mar 2007 11:27:33 +0400, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> This patch adds checking of driver registration status
> and if it fails release allocated resources.
> + if (status_queue) {
> + destroy_workqueue(status_queue);
> + status_queue = NULL;
On Mon, 26 Mar 2007 15:30:42 -0400, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> Regarding the synaptics driver and scroll problem. Yesterday I
> scrolled twice through entire Remarque's "Spark of Life" off lib.ru
> (once with 0.14.2 and once with latest git pull) and did not see any
> scrollbar
On Sun, 25 Mar 2007 23:19:38 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> I tried to reproduce warping on console but could not for some reason. Could
> you
> please try the patch below and tell me if it fixes the problem for you?
> +++ work/drivers/input/mousedev.c
> @@ -124,32 +124,33 @
On Sun, 25 Mar 2007 01:34:02 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > + * Without this, a touchpad may report an unchanged
> > position,
> > + * then a sync. The input_event() eats the position report,
> > but
> > + * lets the sync throug
243.356237, type 3 (Absolute), code 1 (Y), value 1987
<- warp here, by the difference of 3687 and 1987, plus
some small frac_dy value. Easily jumps half the screen.
Event: time 1174703243.356246, -- Report Sync
Signed-off-by: Pete Zaitcev
On Thu, 22 Mar 2007 17:56:13 -0400, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> >>> _Something_ is generating those overcurrent
> >>> warnings, and it sure looks like a hardware malfunction.
> >> But it works with 2.6.20.
> Generation 1 iPod Shuffle is notorious for high current draw.
> You s
On Wed, 7 Mar 2007 17:23:05 -0500, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> It seems that if a process keeps a character device open then other
> processes will also be able to get into filp->f_op->open(inode,filp)
> in chrdev_open() even after a driver called cdev_del() as part of its
> unw
On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys <[EMAIL PROTECTED]> wrote:
> Also more seriously, a somewhat hybrid approach is in order for mode
> setting: simple mode setting isn't much code and is required for sane
> behavior on crash (it is nice to get oopses onto a screen); but the full
> blow
On Fri, 9 Mar 2007 09:28:49 -0500, "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> On 2/28/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Dmitry, please consider getting rid of the list of handles entirely.
> > The other major user is drivers/char/keyboard.c.
On Wed, 7 Mar 2007 17:18:29 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> I've never heard of a process failing to show up in a SysRq-t listing. It
> suggests something is wrong with the process management in the kernel you
> were using. That leads me to think a non -mm kernel might giv
; done
This way, it oopses on 2nd or 3rd disconnect reliably. With the patch,
I can disconnect the mouse 20 times.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
Discussion
One of the race scenarios is related to the list of handles. The cat
calls mousedev_close -> mixdev_rele
On Tue, 27 Feb 2007 09:06:21 -0500, Eric Buddington <[EMAIL PROTECTED]> wrote:
> sd 1:0:0:0: rejecting I/O to offline device
> ...
> SoftDog: Initiating system reboot.
> Now, the USB problem may well be a device or cabling issue, but I
> don't think that this drive failure should trigger a reboot
On Sat, 24 Feb 2007 10:41:15 +0300, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> Thanks a lot for comments and Ack the patch please.
Cyrill, I forgot to mention a couple of points, sorry.
> printk(KERN_INFO "driver %s built at %s on %s\n",
> ftdi_elan_driver.name,
> - _
On Sat, 24 Feb 2007 11:57:07 -0500, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > To tell you the truth, all I really want is to hold a static mutex
> > across a call to input_close_device(). Can I do that?
>
> Are you trying to fix locking in mousedev?
Yes.
-- Pete
-
To unsubscribe from this
On Fri, 23 Feb 2007 11:10:05 +0300, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> I may be wrong, but a lot of the kernel code have static pointers
> initialized to NULL with explicit manner... More over I always thought
> that _static_ is not mean _initialized to zero_. I think _static_ is
> just
1 - 100 of 268 matches
Mail list logo
