On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote:
> Then I moved the USB host controller code to use this new interface.
> That was a bit more complex as it used the struct class and struct
> class_device code directly. As you can see by the patch, the result is
> pretty much identical, and
On Tue, Mar 15, 2005 at 11:51:21AM -0800, Greg KH wrote:
> > Also, it seems to me that you view the class subsystem to be too closely
> > related to /dev entries -- and for these /dev entries class_simple was
> > introduced, IIRC. However, /dev is not the reason the class subsystem was
> > introdu
On Tue, Mar 15, 2005 at 11:34:15AM -0800, Greg KH wrote:
> > And what about device_driver and device structure? Are they going to
> > be changed over to be separately allocated linked objects?
>
> The driver stuff probably will be, and the device stuff possibly.
> However, they are used by a very
On Tue, Mar 15, 2005 at 01:14:40PM -0800, David Brownell wrote:
> That pre-driver model stuff went away in maybe 2.6.5 or so, I
> forget just when. If you think those changes can easily be
> reversed, I suggest you think again ... they enabled a LOT of
> likewise-overdue cleanups.
...
> convertin
On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote:
> > So this means every device will have yet another reference count, and you
> > need to be aware of _each_ lifetime to write correct code. And the
> > _reference counting_ is the hard thing to get right, so we should make
> > _that_ easie
On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote:
> It will not make the reference counting logic easier to get wrong, or
> easier to get right. It totally takes it away from the user, and makes
> them implement it themselves if they so wish (like the USB HCD patch
> does.)
Hi,
While look
Hi,
A quite recent 2.6.19-rc6 got me this oops yesterday -- usually, plug + unplug
work just fine...
[30488.521000] usb 2-2.4: USB disconnect, address 4
[30488.616000] BUG: unable to handle kernel paging request at virtual address
00100100
[30488.616000] printing eip:
[30488.616000] c02e0464
[3
Hi,
git bisect proved that the patch
commit 40f122f343797d02390c5a157372cac0c5b50bb7
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Thu Nov 9 14:44:33 2006 -0500
USB: Add autosuspend support to the hub driver
This patch (as742b) adds autosuspend/autoresume support to the USB hub
dri
Hi,
On Tue, Dec 05, 2006 at 07:19:01AM -0500, Dominik Brodowski wrote:
> Hi,
>
> git bisect proved that the patch
>
> commit 40f122f343797d02390c5a157372cac0c5b50bb7
> Author: Alan Stern <[EMAIL PROTECTED]>
> Date: Thu Nov 9 14:44:33 2006 -0500
>
> USB: A
From: Dominik Brodowski <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2006 21:49:27 -0400
Subject: [PATCH] pcmcia: conf.ConfigBase and conf.Present consolidation
struct pcmcia_device *p_dev->conf.ConfigBase and .Present are set in almost
all PCMICA driver right at the beginning, using the same
Hi,
On Tue, Dec 05, 2006 at 04:39:34PM -0500, Alan Stern wrote:
> > On Tue, Dec 05, 2006 at 07:19:01AM -0500, Dominik Brodowski wrote:
> > > Hi,
> > >
> > > git bisect proved that the patch
> > >
> > > commit 40f122f343797d02390c5a157372cac0
Hi,
On Thu, Dec 07, 2006 at 05:29:32PM -0500, Alan Stern wrote:
> > Any ideas?
>
> No doubt it's caused by the peculiar timing of events at startup. Lots of
> things are happening all at once, and the computer can't keep up with
> everything.
>
> For instance, your log shows the Matrox HD was
Hi,
On Fri, Dec 08, 2006 at 11:00:15AM -0500, Alan Stern wrote:
> Okay. Here's a patch that will print out some information for each of the
> first 100 interrupts received by ehci-hcd. Block yenta-socket from being
> loaded, so as to reduce the number of extraneous interrupts, and see what
>
On Sat, Dec 09, 2006 at 04:03:48PM -0500, Alan Stern wrote:
> > but that did not help:
> >
> > http://userweb.kernel.org/~brodo/dmesg-autosuspend.txt
> >
> > The "offending" IRQ status seems to be 2008; as INTR_MASK does neither
> > include STS_FLR nor STS_RECL (if I got the math correctly), IRQ
On Mon, Dec 11, 2006 at 11:11:08PM -0500, Alan Stern wrote:
> On Mon, 11 Dec 2006, Dominik Brodowski wrote:
>
> > > Yes, that's right. In fact the controller isn't supposed to send an IRQ
> > > when only those two bits are on. I suspect the STS_FLR bit i
On Tue, Dec 12, 2006 at 11:27:42AM -0500, Alan Stern wrote:
> > from today confirms it, and I also ran the pre-autosuspend kernel ( its head
> > is 8c03356a559ced6fa78931f498193f776d67e445 ) to re-check that it is an
> > issue
> > which appeared with the autosuspend patch.
>
> Okay, I was fooled
Hi,
Sorry for not getting back to you earlier -- many things kept me distracted:
On Tue, Dec 12, 2006 at 04:08:39PM -0500, Alan Stern wrote:
> On Tue, 12 Dec 2006, Dominik Brodowski wrote:
>
> > > On the other hand, your latest log suggests that the STS_FLR bit gets set
&
Hi,
On Mon, Jan 29, 2007 at 10:41:58AM -0500, Alan Stern wrote:
> On Sun, 28 Jan 2007, Dominik Brodowski wrote:
>
> > > You could try another test: Let the IRQ be disabled, and then rmmod
> > > ehci-hcd and modprobe it back. Perhaps then rmmod usb-storage to forc
Hi,
On Tue, Jan 30, 2007 at 10:50:19AM -0500, Alan Stern wrote:
> On Mon, 29 Jan 2007, Dominik Brodowski wrote:
>
> > Allright, done some more debugging:
> > - using my patch with your fix, devices which are already plugged in when
> > the STS_FLR exception
Hi,
On Tue, Jan 30, 2007 at 03:31:24PM -0500, Alan Stern wrote:
> > next test:
> > http://userweb.kernel.org/~brodo/pre-insert
> > => added device 2
> > http://userweb.kernel.org/~brodo/post-insert
>
> These were all done with the controller supposedly suspended, right?
Yes.
> But
> they all s
On Tue, Apr 18, 2006 at 09:45:50AM -0400, Alan Stern wrote:
> On Tue, 18 Apr 2006 [EMAIL PROTECTED] wrote:
> > Also the PCMCIA subsystem's behavior is to power off the socket
> > irrespective of whether the PCMCIA client driver has successfully
> > handled the SUSPEND event or not.
>
> I don't kno
21 matches
Mail list logo
