On Tue, 11 Oct 2005, Greg KH wrote:
>
> Ugh, but it looks like Linus already committed your previous patch, with
> some changes by him. Care to send a delta from what is currently in his
> tree (2.6.14-rc4 has it) and this patch?
I _think_ I fixed the disconnect thing too, although I think Har
On Tue, Oct 11, 2005 at 11:45:51AM +0200, Harald Welte wrote:
> On Mon, Oct 10, 2005 at 11:07:45AM -0700, Chris Wright wrote:
> > * Harald Welte ([EMAIL PROTECTED]) wrote:
> > > diff --git a/kernel/signal.c b/kernel/signal.c
> > > --- a/kernel/signal.c
> > > +++ b/kernel/signal.c
> > > @@ -1193,6 +
Matt
I want to make use of patch for non pci ehci but couldn't really figure out
where to get it.
Where do I obtain this patch ?
Which linux kernel version needs to be used/downloaded in order to use this
patch cleanly ? Is any linux kernel available that already includes this
patch ?
After app
Bill Rees wrote:
There appears to be a bug in usb/usb-skeleton.c. At least up
through 2.6.14-rc4. The original code generates a read pipe id for
the write output pipe.
bill rees
--- usb-skeleton.c 2005-09-26 20:09:39.0 -0700
+++ usb-skeleton.mod.c 2005-10-11 14:55:27.81
On Tue, 11 Oct 2005, Ivan Kalatchev wrote:
> I've tested your new patch. Everything works just fine. Host controller is
> restarted and alive after board is resumed.
> The only tricky moment is if user forgot to unmount memory stick before
> sending board to sleep. Say it was mounted as /dev/sda
There appears to be a bug in usb/usb-skeleton.c. At least up
through 2.6.14-rc4. The original code generates a read pipe id for the
write output pipe.
bill rees
--- usb-skeleton.c 2005-09-26 20:09:39.0 -0700
+++ usb-skeleton.mod.c 2005-10-11 14:55:27.815537470 -0700
@@ -2
On Tue, Oct 11, 2005 at 03:13:39PM -0400, Alan Stern wrote:
> Surely Linux uses entirely original code, with no hangovers from the
> original AT&T Unix... Besides, to the best of my recollection, the two
> operations are equal in speed on a PDP-11.
I've no idea but I don't believe the relative sp
On Tue, 11 Oct 2005, Franck wrote:
> > Consider a simple example of reading:
> >
> > spin_lock(&urb->lock);
> > if (urb->status == -EINPROGRESS)
> > printk("URB is in progress\n");
> > else
> > printk("URB is not in progress\n");
> >
On Tue, 11 Oct 2005, linux-os (Dick Johnson) wrote:
> On Tue, 11 Oct 2005, Paul Jackson wrote:
>
> > Alan asked:
> >> But why do people go to the
> >> effort of confusing readers by using "^" instead of "!="?
> >
> > My guess - eor (^) was quicker than not-equal (!=) on a PDP-11.
> >
> > That cod
2005/10/11, Alan Stern <[EMAIL PROTECTED]>:
> On Tue, 11 Oct 2005, Franck wrote:
>
> > 2005/10/11, Alan Stern <[EMAIL PROTECTED]>:
> > > Be more careful here. It doesn't hold urb->lock while _reading_
> > > urb->status; there's no point. But it does hold urb->lock while
> > > _writing_ urb->statu
On Tue, 11 Oct 2005, Paul Jackson wrote:
> Alan asked:
>> But why do people go to the
>> effort of confusing readers by using "^" instead of "!="?
>
> My guess - eor (^) was quicker than not-equal (!=) on a PDP-11.
>
> That code fragment for checking uid's has been around a -long-
> time, if my m
Alan asked:
> But why do people go to the
> effort of confusing readers by using "^" instead of "!="?
My guess - eor (^) was quicker than not-equal (!=) on a PDP-11.
That code fragment for checking uid's has been around a -long-
time, if my memory serves me.
It's gotten to be like the infamous
On Tue, 11 Oct 2005, Franck wrote:
> 2005/10/11, Alan Stern <[EMAIL PROTECTED]>:
> > Be more careful here. It doesn't hold urb->lock while _reading_
> > urb->status; there's no point. But it does hold urb->lock while
> > _writing_ urb->status. That is necessary.
> >
>
> hmm, sorry but I don't
2005/10/11, Alan Stern <[EMAIL PROTECTED]>:
> Be more careful here. It doesn't hold urb->lock while _reading_
> urb->status; there's no point. But it does hold urb->lock while
> _writing_ urb->status. That is necessary.
>
hmm, sorry but I don't see why it needs a lock while writing but not
whil
On Tue, 11 Oct 2005, Franck wrote:
> still tracking my bug...I just have 2 questions, I looked at uhci hcd
> to have an idea on how interrupts and locks must be handled in
> hcd->urb_enqueue method. uhci hcd simply disables IT in this method,
> so every allocations are atomic and mem_flags paramet
Alan
2005/10/10, Alan Stern <[EMAIL PROTECTED]>:
> The only way it can happen is if your HCD set urb->hcpriv to NULL earlier,
> or never set it to a non-NULL value. It must be a bug in the HCD.
>
still tracking my bug...I just have 2 questions, I looked at uhci hcd
to have an idea on how interru
On Mon, 2005-10-10 at 11:07 -0700, Chris Wright wrote:
> * Harald Welte ([EMAIL PROTECTED]) wrote:
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -1193,6 +1193,40 @@ kill_proc_info(int sig, struct siginfo *
> > return error;
> > }
On Mon, Oct 10, 2005 at 04:03:13PM -0400, Alan Stern wrote:
> On Mon, 10 Oct 2005, Harald Welte wrote:
>
> > + if ((!info || ((unsigned long)info != 1 &&
> > + (unsigned long)info != 2 && SI_FROMUSER(info)))
> > + && (euid ^ p->suid) && (euid ^ p->uid)
> > + && (uid
On Mon, Oct 10, 2005 at 11:07:45AM -0700, Chris Wright wrote:
> * Harald Welte ([EMAIL PROTECTED]) wrote:
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -1193,6 +1193,40 @@ kill_proc_info(int sig, struct siginfo *
> > return error;
> There will be three separate drivers: host, client, otg transceiver
> (for ULPI system not a really transceiver driver).
Rather than "transceiver" driver, I'd say "OTG" driver ... the thing
responsible for role detection and switching. So for drivers that
touch hardware, (a) OTG driver, (b) HCD
On Wed, 2005-09-28 at 17:01 -0700, Pete Zaitcev wrote:
> > - request_module() is icky. I keep wanting to get rid of that
> > function, and really don't want to see any further users get added.
> > But that's just my feeling, if there's no other way to do this, I
> > don't mind.
>
>
21 matches
Mail list logo
