Am Dienstag, 6. Februar 2007 14:34 schrieb Oleg Verych:
> On Tue, Feb 06, 2007 at 01:18:13PM +0100, Oliver Neukum wrote:
> > Am Dienstag, 6. Februar 2007 12:31 schrieb Joris van Rantwijk:
> > > A spinlock should certainly be sufficient. I think spinlocks have a
> > > memory barrier built-in, other
On Tue, Feb 06, 2007 at 01:18:13PM +0100, Oliver Neukum wrote:
> Am Dienstag, 6. Februar 2007 12:31 schrieb Joris van Rantwijk:
> > A spinlock should certainly be sufficient. I think spinlocks have a
> > memory barrier built-in, otherwise they would be pretty useless.
>
> They do, as do all locks
On 6 feb 2007, at 13:18, Oliver Neukum wrote:
>>> And 'volatile' in C have nothing to do with hardware: SMP, caches or
>>> whatever there may be.
>>
>> The problem that we're trying to solve has not much to do with
>> hardware. I'd like to solve it at a pure logical level: by using some
>> interfac
On 6 feb 2007, at 11:38, Oliver Neukum wrote:
>> What I really want is ordered access and volatility. I want exactly
>> the
>> kind of semantics that Java defines for volatile variables.
>
> A spinlock will surely do that. For the time being I'll push your first
> three patches forward and we can
> From: Oliver Neukum
> Newsgroups: gmane.linux.usb.devel
> Subject: Re: CDC-ACM driver: data duplication due to throttling
> Date: Tue, 6 Feb 2007 11:38:09 +0100
Hallo.
> To:
[]
> Am Dienstag, 6. Februar 2007 10:38 schrieb Joris van Rantwijk:
>> On 5 feb 2007, at 23:07, Alan wrote:
>> > atomic_
Am Dienstag, 6. Februar 2007 10:38 schrieb Joris van Rantwijk:
> On 5 feb 2007, at 23:07, Alan wrote:
> > atomic_t on many platforms isn't that efficient and there are more
> > cases
> > where the atomic bit operations are fast. How about using
> > test_bit/set_bit/clear_bit/etc
>
> I don't know.
On 5 feb 2007, at 23:07, Alan wrote:
> atomic_t on many platforms isn't that efficient and there are more
> cases
> where the atomic bit operations are fast. How about using
> test_bit/set_bit/clear_bit/etc
I don't know. The thing is, I want something different from atomicity.
In itself, atomica
Am Montag, 5. Februar 2007 22:26 schrieb Joris van Rantwijk:
> One more thing to bother you with ;-)
>
> Since acm->throttle_lock is only used to protect the simple flag byte
> acm->throttle, it is somewhat more efficient and convenient to use
> an atomic_t instead of a spinlock.
Do you feel like
On Mon, 5 Feb 2007 22:26:14 +0100
Joris van Rantwijk <[EMAIL PROTECTED]> wrote:
> One more thing to bother you with ;-)
>
> Since acm->throttle_lock is only used to protect the simple flag byte
> acm->throttle, it is somewhat more efficient and convenient to use
> an atomic_t instead of a spinloc
One more thing to bother you with ;-)
Since acm->throttle_lock is only used to protect the simple flag byte
acm->throttle, it is somewhat more efficient and convenient to use
an atomic_t instead of a spinlock.
The included patch makes these changes. It applies on top of the most
recent version of
On Sun, Feb 04, 2007 at 11:18:13PM +0100, Oliver Neukum wrote:
> Still, this would be untested, while delaying the buffers for later
> processing is tested.
Tested indeed, by me, and shown to deliver duplicate data.
But apart from that, I think you are right to push for the most
careful change.
>
Am Sonntag, 4. Februar 2007 22:45 schrieben Sie:
> Hello Oliver,
>
> On Sun, Feb 04, 2007 at 09:59:00PM +0100, Oliver Neukum wrote:
> > Did you test this with ehci? Unless we know for sure that even with
> > the larger packet size the tty layer can cope, I want to be conservative.
>
> Good point.
Hello Oliver,
On Sun, Feb 04, 2007 at 09:59:00PM +0100, Oliver Neukum wrote:
> Did you test this with ehci? Unless we know for sure that even with
> the larger packet size the tty layer can cope, I want to be conservative.
Good point. No I didn't, my device does not do high speed.
The tty layer
Am Samstag, 3. Februar 2007 17:10 schrieben Sie:
> On Sat, Feb 03, 2007 at 04:18:24PM +0100, Oliver Neukum wrote:
> > 1. Why not simply take the lock earlier?
>
> And call the tty layer under acm->throttle_lock? I think not.
No, it would deadlock, you are right.
> We could of course read acm->th
On Sat, Feb 03, 2007 at 04:18:24PM +0100, Oliver Neukum wrote:
> 1. Why not simply take the lock earlier?
And call the tty layer under acm->throttle_lock? I think not.
We could of course read acm->throttle once under the lock and
store its value in a local variable. I can write it like that if
yo
Am Samstag, 3. Februar 2007 15:51 schrieb Joris van Rantwijk:
> There seems to be a bug in the handling of device throttling in the
> CDC-ACM driver. When the tty requests throttling, the same packet
> is sometimes delivered to the tty and also pushed back on the list
> of pending packets, resultin
There seems to be a bug in the handling of device throttling in the
CDC-ACM driver. When the tty requests throttling, the same packet
is sometimes delivered to the tty and also pushed back on the list
of pending packets, resulting in delivery of duplicate data.
The problem is inside acm_rx_tasklet
17 matches
Mail list logo
