from
power saving idle a lot more than needed...
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
drivers/usb/core/hcd.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6.22-rc2/drivers/usb/core/hcd.c
On Mon, 2006-11-06 at 15:46 +0300, Andrey Borzenkov wrote:
I presume this is lockdep; this looks initially truncated,
unfortunately this
is how it was stored in messages. I will try to get more complete
output ig
required.
the interesting bits are missing unfortunately (the first 10 lines
On Tue, 2006-10-31 at 20:56 +0100, Adrian Bunk wrote:
This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or
On Thu, 2006-07-13 at 13:12 +0530, [EMAIL PROTECTED] wrote:
We've written a device driver in linux for a pcmcia card with usb and
serial functionality. I need to test this driver on a dual core/SMP
machine. We work on kernel 2.6.15.4. I have recompiled this kernel
version on my dual core
tty_insert_flip_string() returns number of bytes it has actually
inserted, but I don't believe one can do much if it returns less than
has been requested as it means that we are out of kernel memory.
Yes. I've been wondering if we should log the failure case somewhere,
either as a tty-
a few remarks and questions:
On 27.02.2006, Arjan van de Ven wrote:
as a general review remark: you seem to use a LOT of atomic variables.
This I think is not too good an approach in general, because you get
into all kinds of race situations if you need to access multiple (and
you do
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
+#define IFNULL(a) \
+ if (unlikely(!(a)))
please please get rid of this!
first of all, gcc ALREADY treats null pointer checks as unlikely,
second of all this makes code entirely unreadable, so please just
use if (!a) where you
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
+static inline void new_index(atomic_t *index, int max)
+{
+ if (atomic_read(index) == max) //FIXME race?
+ atomic_set(index, 0);
+ else
+ atomic_inc(index);
+}
yes.. that's a race.
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
+ }
+
+ spin_lock_irqsave(cs-lock, flags);
+ ret = kmalloc(sizeof(struct at_state_t), GFP_ATOMIC);
+ if (ret) {
+ gigaset_at_init(ret, NULL, cs, cid);
if you move the kmalloc one line
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
+ struct semaphore sem; /* locks this structure:
+ * connected is not changed,
+ * hardware_up is not changed,
+
On Mon, 2006-02-27 at 07:23 +0100, Hansjoerg Lipp wrote:
The following patches add drivers for the Siemens Gigaset 3070 family of
ISDN DECT PABXes connected via USB, either directly or over a DECT link
using a Gigaset M105 or compatible DECT data adapter. The devices are
integrated as ISDN
On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
I think we can assume that it will be seen there. 2.6.16 is going into
distros and will have more
I have this vaguely unsettled feeling that distros must get more bug
reports than the usptream developers, yet we hear so little about it
the number of quality reports (eg enough information to do anything)
isn't that high; Dave is pretty good in sending the good ones on, it
often takes time
On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
Brown, Len [EMAIL PROTECTED] wrote:
My point is that it that on the grand scale of bugs serious enough
to have an effect on the course of 2.6.16, this one doesn't qualify
unless the same issue is seen on other systems.
I think
pointer target type
In current GIT trees that line seems to be several lines earlier in the
file, and simple_dir_operations has no qualifier.
Yes, simple_dir_operations is const in -mm.
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
--- linux-2.6.15/drivers/usb/gadget/inode.c.org 2006-01
Isn't it right? Is the URB write so fast that switching to atomic_t
doesn't pay-off?
an atomic_t access and a spinlock are basically the same price... so
what's the payoff ?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
On Wed, 2005-12-07 at 10:30 -0200, Luiz Fernando Capitulino wrote:
On Wed, 07 Dec 2005 13:27:13 +0100
Arjan van de Ven [EMAIL PROTECTED] wrote:
|
| Isn't it right? Is the URB write so fast that switching to atomic_t
| doesn't pay-off?
|
| an atomic_t access and a spinlock
On the other hand, Oliver needs to be careful about claiming too much. In
general atomic_t operations _are_ superior to the spinlock approach.
No they're not. Both are just about equally expensive cpu wise,
sometimes the atomic_t ones are a bit more expensive (like on parisc
architecture).
On Wed, 2005-12-07 at 16:37 +0100, Oliver Neukum wrote:
Am Mittwoch, 7. Dezember 2005 16:22 schrieb Arjan van de Ven:
On the other hand, Oliver needs to be careful about claiming too much.
In
general atomic_t operations _are_ superior to the spinlock approach.
No they're
No they're not. Both are just about equally expensive cpu wise,
sometimes the atomic_t ones are a bit more expensive (like on parisc
architecture). But on x86 in either case it's a locked cycle, which is
just expensive no matter which side you flip the coin...
But if a lock is used
On Wed, 2005-12-07 at 11:01 -0500, Alan Stern wrote:
On Wed, 7 Dec 2005, Arjan van de Ven wrote:
On the other hand, Oliver needs to be careful about claiming too much.
In
general atomic_t operations _are_ superior to the spinlock approach.
No they're not. Both are just about
On Tue, 2005-12-06 at 09:57 -0200, Luiz Fernando Capitulino wrote:
Introduces URB write locking macros.
ugh.. WHY ?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new
On Mon, 2005-11-14 at 18:37 +0100, Harald Welte wrote:
Make usbdevice_fs.h (again) useable from userspace
If we have CONFIG_COMPAT enabled, then userspace programs using
usbdevice_fs.h won't compile anymore.
how does the userspace application set CONFIG_COMPAT??
On Tue, 2005-10-18 at 11:49 -0700, Pete Zaitcev wrote:
The problem here is that compat_ptr does NOT turn user data pointer
into a kernel pointer. It's still a user pointer, only sized
differently. So, when you do set_fs(KERNEL_DS), this pointer
is invalid (miraclously, it does work on
On Tue, 2005-07-05 at 12:36 +0200, Duncan Sands wrote:
I wonder why the invocations of kmalloc are needed in these functions.
Because some architectures can't do DMA to/from the stack.
doing dma to/from kmalloc also isn't too nice... should be using
dma_alloc_*() API I guess
25 matches
Mail list logo
