Am Freitag, 23. September 2005 10:45 schrieb Duncan Sands:
> > > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > > irqsave. It will just be slower. But in a tasklet or interrupt handler
> > > spin_lock() will do. Basically these locks differ in whether they shut
> > >
> I see, thanks for your constructive comments. I'll have a detailed look
> at these kernel programming basics, in case I'd have to hack my way
> through again some day. ;) Can you tell me in which kernel version will
> the patch appear?
It is not up to me. I've just returned and will generate a
Am Freitag, 23. September 2005 16:53 schrieb Duncan Sands:
> > > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > > irqsave. It will just be slower. But in a tasklet or interrupt handler
> > > spin_lock() will do. Basically these locks differ in whether they shut
> > >
Hello Alan,
i am really sorry for all the mess.
But thank you very much for giving the information.
Thanks
On 9/23/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Sep 2005, Oliver Neukum wrote:
>
> > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > irqsave. It wi
> > What's more, in the particular case of urb completion callbacks there is
> > no guarantee that the callback is even called from an interrupt.
>
> Right, although there is a guarantee that local interrupts will be
> disabled when the completion handler is called. That guarantee may be
> remo
On Fri, 23 Sep 2005, Duncan Sands wrote:
> > This may depend on the particular architecture or platform. On x86,
> > general interrupts are not always disabled during interrupt handlers.
> > Only the particular IRQ line being handled.
>
> What's more, in the particular case of urb completion c
On Fri, 23 Sep 2005, Conio sandiago wrote:
> Hello Alen
> actually i am not porting the in built kernel ehci driver
> i am porting the driver which is developed for my specific hardware,
> so i am only defining two functions for my driver i.e.
> ehci_hardware_probe and ehci_hardware_remove
If you
> > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > irqsave. It will just be slower. But in a tasklet or interrupt handler
> > spin_lock() will do. Basically these locks differ in whether they shut down
> > irq processing on the local CPU. In interrupt it is down and mu
Hello Alen
actually i am not porting the in built kernel ehci driver
i am porting the driver which is developed for my specific hardware,
so i am only defining two functions for my driver i.e.
ehci_hardware_probe and ehci_hardware_remove
i have registeded my driver in 2.6.10
but i m facing the pro
On Fri, 23 Sep 2005, Oliver Neukum wrote:
> A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> irqsave. It will just be slower. But in a tasklet or interrupt handler
> spin_lock() will do. Basically these locks differ in whether they shut down
> irq processing on the local
On Fri, 23 Sep 2005, Conio sandiago wrote:
> Hi all
> I am porting the Linux EHCI usb driver for 2.6.9 kernel to 2.6.10 kernel
> During this i was facing following problems in compilation -
This may be a stupid question, but why do you need to port the EHCI driver
from 2.6.9 to 2.6.10? 2.6.10 a
Hi all
I am porting the Linux EHCI usb driver for 2.6.9 kernel to 2.6.10 kernel
During this i was facing following problems in compilation -
1) hcd_alloc function is not present , so i replaced it with usb_create_hcd
2) hcd_free function is not present , so i replaced it with hcd_buffer_destroy
> > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > irqsave. It will just be slower. But in a tasklet or interrupt handler
> > spin_lock() will do. Basically these locks differ in whether they shut down
> > irq processing on the local CPU. In interrupt it is down and mu
On Fri, Sep 23, 2005 at 06:05:37AM +0200, Oliver Neukum wrote:
> Am Freitag, 23. September 2005 00:49 schrieb David Kubicek:
> > Ok, so what does that mean for me now? Should I change those to normal
> > spin_locks too? Locks I used are not there "by design" it's just the way
> > a similar piece of
Am Freitag, 23. September 2005 00:49 schrieb David Kubicek:
> On Fri, Sep 23, 2005 at 12:07:23AM +0200, Oliver Neukum wrote:
> > Am Mittwoch, 21. September 2005 20:04 schrieb David Kubicek:
> > > On Wed, Sep 21, 2005 at 06:32:05PM +0200, Oliver Neukum wrote:
> > > > Am Mittwoch, 21. September 2005
On Fri, Sep 23, 2005 at 12:07:23AM +0200, Oliver Neukum wrote:
> Am Mittwoch, 21. September 2005 20:04 schrieb David Kubicek:
> > On Wed, Sep 21, 2005 at 06:32:05PM +0200, Oliver Neukum wrote:
> > > Am Mittwoch, 21. September 2005 14:51 schrieb David Kubicek:
>
> > > This is in interrupt. Please u
Am Mittwoch, 21. September 2005 20:04 schrieb David Kubicek:
> On Wed, Sep 21, 2005 at 06:32:05PM +0200, Oliver Neukum wrote:
> > Am Mittwoch, 21. September 2005 14:51 schrieb David Kubicek:
> > This is in interrupt. Please use the simple form of the locks.
> I'd like to find out the difference be
On Wed, 21 Sep 2005, David Kubicek wrote:
> On Wed, Sep 21, 2005 at 06:32:05PM +0200, Oliver Neukum wrote:
> > Am Mittwoch, 21. September 2005 14:51 schrieb David Kubicek:
> > > Hello all,
> > >
> > > I am sorry for being so slow with the new patch - didn't really have
> > > time for hacking on th
On Wed, Sep 21, 2005 at 06:32:05PM +0200, Oliver Neukum wrote:
> Am Mittwoch, 21. September 2005 14:51 schrieb David Kubicek:
> > Hello all,
> >
> > I am sorry for being so slow with the new patch - didn't really have
> > time for hacking on that last month. This patch is against the latest
> > st
On Wed, Aug 31, 2005 at 02:02:23PM +0200, Oliver Neukum wrote:
> On Wed, 31 Aug 2005, Petr Pisar wrote:
> > Oliver Neukum neukum.org> writes:
> > > > > Do you happen to have an URL?
> > > > > I'd like to include it in 2.6.14.
> > > >
> > >
> > > > informed. The latest version is at
> > > > [htt
On Wed, 31 Aug 2005, Petr Pisar wrote:
> Oliver Neukum neukum.org> writes:
> > > > Do you happen to have an URL?
> > > > I'd like to include it in 2.6.14.
> > >
> >
> > > informed. The latest version is at
> > > [http://dave.ok.cz/cdc-acm_release/linux-2.6.12-rc5_stable-cdc-acm.patch].
> > >
Oliver Neukum neukum.org> writes:
> > > Do you happen to have an URL?
> > > I'd like to include it in 2.6.14.
> >
>
> > informed. The latest version is at
> > [http://dave.ok.cz/cdc-acm_release/linux-2.6.12-rc5_stable-cdc-acm.patch].
> > It should run in 2.6.12-rc5 but I'm not sure, I have not
> > Do you happen to have an URL?
> > I'd like to include it in 2.6.14.
>
> You are _that_ guy, who reviewed the code. So you should be better
Yes, I am emerging from chaos right. I was very busy the last months.
Sorry.
> informed. The latest version is at
> [http://dave.ok.cz/cdc-acm_release
Oliver Neukum napsal(a):
Am Dienstag, 30. August 2005 21:35 schrieb Petr Pisar:
Greg Lee napsal(a):
Currently I've made a preliminary firmware for implementing the
CDC-ACM interface, however as Pavel kindly pointed out for me,
currently only 64Kbyte/sec is achieveable with this driver. I've
Am Dienstag, 30. August 2005 21:35 schrieb Petr Pisar:
> Greg Lee napsal(a):
> >>>Currently I've made a preliminary firmware for implementing the
> >>>CDC-ACM interface, however as Pavel kindly pointed out for me,
> >>>currently only 64Kbyte/sec is achieveable with this driver. I've read
> >>>t
Greg Lee napsal(a):
Currently I've made a preliminary firmware for implementing the
CDC-ACM interface, however as Pavel kindly pointed out for me,
currently only 64Kbyte/sec is achieveable with this driver. I've read
the archives and from the discussions, I suspect that this is
connected to t
26 matches
Mail list logo
