[linux-usb-devel] Patch to align the various USB timers to fire at the same time
This patch modifies the USB regular 250ms timer to be perfectly aligned to the second and quarters thereof. This change is there to make sure that if you have multiple USB ports, the timers for all these ports will fire at the same time rather than all spread out. All spread out wakes the CPU up 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 === --- linux-2.6.22-rc2.orig/drivers/usb/core/hcd.c +++ linux-2.6.22-rc2/drivers/usb/core/hcd.c @@ -582,10 +582,12 @@ void usb_hcd_poll_rh_status(struct usb_h } /* The USB 2.0 spec says 256 ms. This is close enough and won't -* exceed that limit if HZ is 100. */ +* exceed that limit if HZ is 100. The math is more clunky than +* maybe expected, this is to make sure that all timers for USB devices +* fire at the same time to give the CPU a break inbetween */ if (hcd-uses_new_polling ? hcd-poll_rh : (length == 0 hcd-status_urb != NULL)) - mod_timer (hcd-rh_timer, jiffies + msecs_to_jiffies(250)); + mod_timer (hcd-rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)); } EXPORT_SYMBOL_GPL(usb_hcd_poll_rh_status); @@ -614,8 +616,8 @@ static int rh_queue_status (struct usb_h urb-hcpriv = hcd; /* indicate it's queued */ if (!hcd-uses_new_polling) - mod_timer (hcd-rh_timer, jiffies + - msecs_to_jiffies(250)); + mod_timer (hcd-rh_timer, + (jiffies/(HZ/4) + 1) * (HZ/4)); /* If a status change has already occurred, report it ASAP */ else if (hcd-poll_pending) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.18.2: lockdep warnings on rmmod ohci_hcd
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 or so). Also this will be in dmesg if your system actually survives... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.19-rc4: known unfixed regressions
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 driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: PCI: MMCONFIG breakage References : http://lkml.org/lkml/2006/10/27/251 Submitter : Jeff Chua [EMAIL PROTECTED] Status : unknown, both BIOS and Direct work hmm I see nothing MMCONFIG related here much - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Expertise required on building code for SMP
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 machine with the CONFIG_SMP flag set during menuconfig. How do i ensure that my driver is making use of the SMP feature? Do build my driver code i have a makefile in which i use the EXTRA_CFLAGS= -D__SMP__ -DCONFIG_SMP -DLINUX. NO! You should just use a normal KBuild makefile, and not ever add any extra cflags (but you failed to provide a URL to even your Makefile but also to your code so it's hard to give you a detailed recommendation) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Airprime driver improvements to allow full speed EvDO transfers
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- object or printk. printk gets... interesting if you use serial console ;) both locking and buffer space wise Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 0/7] isdn4linux: add drivers for Siemens Gigaset ISDN DECT PABX
On Fri, 2006-03-03 at 00:03 +0100, Tilman Schmidt wrote:
Thank you very much, Arjan, for your review of our code and your
extensive comments. We are working on taking them into account for the
next attempt at submitting the driver. Most of them are quite clear and
don't need discussing. Just 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).
I see. We'll try to reduce our atomic consumption. :-)
In addition I've seen a lot of your code using 2 or more
atomics in the same function, at which point it's most likely cheaper to
just have a spinlock instead... (yes a single atomic is same cost as a
spinlock, but once you do multiple in the same function the price is
thus higher than a spinlock ;)
So you are saying that, for example
spin_lock_irqsave(cs-ev_lock, flags);
head = cs-ev_head;
tail = cs-ev_tail;
spin_unlock_irqrestore(cs-ev_lock, flags);
is (mutatis mutandis) actually cheaper than
head = atomic_read(cs-ev_head);
tail = atomic_read(cs-ev_tail);
atomic_read is special since it's not actually an atomic operation ;)
but.. think about it: you do 2 atomic reads, however there is ZERO
guarantee that the reads are atomic with respect to eachother; eg your
head and tail are not an atomic snapshot of these 2 variables!
+#define IFNULL(a) \
+ if (unlikely(!(a)))
please please get rid of this!
(same goes for the variants of this just below this)
Ok, these were mainly debugging aids. We'll just drop them and let the
oops mechanism catch the (hopefully non-existent) remaining cases of
pointers being unexpectedly NULL.
you can also use WARN_ON() and BUG_ON() for that, you then get a more
readable oops message (with filename and line information)
+void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
+ size_t len, const unsigned char *buf, int from_user)
such from_user parameter is highly evil, and also breaks sparse and
friends.. (btw please run sparse on the code and fix all warnings)
Are you referring to anything in particular? We do run sparse regularly,
and it did not emit any warnings for the submitted version, not even for
this function. (But heaps of them for other parts of the kernel, if you
pardon the remark.)
msg should have the __user atribute here since it can be in userspace...
sometimes. It is the sometimes that is the bad idea!
+ 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 up, can it use GFP_KERNEL ?
Sorry but no - this is executed within a tasklet.
ok fair enough ;)
(GFP_ATOMIC is evil in the sense that spurious use of it gives trouble
for the VM)
Does that mean that every function doing kmalloc() and which may be
called from both interrupt and non-interrupt context needs a gfp_t flags
argument?
well that's the other extreme. But if it's going to be a major source of
memory allocations, yes. If it's only sometimes, or a few, then no.
For example if your tasklet function allocates one, and then frees it
before being done, I don't see a problem. It becomes a problem when
there will be many of these, and when they have longer lifetimes,
because then the vm can become starved of memory before it has a chance
to do correct the memory imbalance.
(GFP_ATOMIC is like borrowing from the VM, the VM will be in slight
imbalance afterwards. With GFP_KERNEL you allow the kernel to fix this
imbalance. A slight imbalance is fine and not a problem. Especially if
you give it the memory back soon. But if the imbalance can accumulate,
for example because you keep allocating and free the memory much later,
it can become a problem)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 1/7] isdn4linux: Siemens Gigaset drivers - common module
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 would want to use IFNULL (same goes for the variants of this just below this) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 2/7] isdn4linux: Siemens Gigaset drivers - event layer
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.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 2/7] isdn4linux: Siemens Gigaset drivers - event layer
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 up, can it use GFP_KERNEL ?
(GFP_ATOMIC is evil in the sense that spurious use of it gives trouble
for the VM)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 1/7] isdn4linux: Siemens Gigaset drivers - common module
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,
+ * MState is not changed to or from
+ * MS_LOCKED */
+
please turn this into a mutex
+/* handling routines for sk_buff */
+/* = */
+
+/* private version of __skb_put()
+ * append 'len' bytes to the content of 'skb', already knowing that the
+ * existing buffer can accomodate them
+ * returns a pointer to the location where the new bytes should be copied to
+ * This function does not take any locks so it must be called with the
+ * appropriate locks held only.
+ */
+static inline unsigned char *gigaset_skb_put_quick(struct sk_buff *skb,
+unsigned int len)
+{
+ unsigned char *tmp = skb-tail;
+ /*SKB_LINEAR_ASSERT(skb);*/ /* not needed here */
+ skb-tail += len;
+ skb-len += len;
+ return tmp;
+}
this looks truely scary and wrong
+/* append received bytes to inbuf */
+static inline int gigaset_fill_inbuf(struct inbuf_t *inbuf,
+ const unsigned char *src,
+ unsigned numbytes)
+{
+ unsigned n, head, tail, bytesleft;
+
+ gig_dbg(DEBUG_INTR, received %u bytes, numbytes);
+
+ if (!numbytes)
[snip 30 lines]
isn't this function rather big to be inlined ?
+
+/*==
+ Prototypes of internal functions
+ */
+
+static struct cardstate *alloc_cs(struct gigaset_driver *drv);
+static void free_cs(struct cardstate *cs);
+static void make_valid(struct cardstate *cs, unsigned mask);
+static void make_invalid(struct cardstate *cs, unsigned mask);
most of the time these can just go away by ordering the functions better
+
+void gigaset_dbg_buffer(enum debuglevel level, const unsigned char *msg,
+ size_t len, const unsigned char *buf, int from_user)
such from_user parameter is highly evil, and also breaks sparse and
friends.. (btw please run sparse on the code and fix all warnings)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 0/7] isdn4linux: add drivers for Siemens Gigaset ISDN DECT PABX
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 adapters within the isdn4linux framework, supporting incoming and outgoing voice and data connections, and also as tty devices providing access to device specific AT commands. 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). In addition I've seen a lot of your code using 2 or more atomics in the same function, at which point it's most likely cheaper to just have a spinlock instead... (yes a single atomic is same cost as a spinlock, but once you do multiple in the same function the price is thus higher than a spinlock ;) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Linux 2.6.16-rc3
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 exposure than 2.6.15, 2.6.15 went into distros as well, such as Fedora Core 4 ;) And promptly broke laptop suspension. See, for example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998 fedora core 4 never really supported suspend in the first place tho.. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Linux 2.6.16-rc3
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 though to get all the basic info.. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: Linux 2.6.16-rc3
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 we can assume that it will be seen there. 2.6.16 is going into distros and will have more exposure than 2.6.15, 2.6.15 went into distros as well, such as Fedora Core 4 ;) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB on alpha
On Thu, 2006-01-12 at 23:33 -0800, Andrew Morton wrote:
David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 11 January 2006 2:54 am, Andrew Morton wrote:
I'm getting bored of fixing these things. It's someone else's turn ;)
Here's a patch that should solve the net2280 one,
Danke.
but I'm not clear why this one happens:
Because Arjan is a very bad person!
bad to the bone ;)
drivers/usb/gadget/inode.c: In function `gadgetfs_fill_super':
drivers/usb/gadget/inode.c:2035: warning: passing arg 3 of
`gadgetfs_make_inode' discards qualifiers from 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-13 08:53:28.0
+0100
+++ linux-2.6.15/drivers/usb/gadget/inode.c 2006-01-13 08:54:39.0
+0100
@@ -1582,7 +1582,7 @@
static struct inode *
gadgetfs_create_file (struct super_block *sb, char const *name,
- void *data, struct file_operations *fops,
+ void *data, const struct file_operations *fops,
struct dentry **dentry_p);
static int activate_ep_files (struct dev_data *dev)
@@ -1957,7 +1957,7 @@
static struct inode *
gadgetfs_make_inode (struct super_block *sb,
- void *data, struct file_operations *fops,
+ void *data, const struct file_operations *fops,
int mode)
{
struct inode *inode = new_inode (sb);
@@ -1981,7 +1981,7 @@
*/
static struct inode *
gadgetfs_create_file (struct super_block *sb, char const *name,
- void *data, struct file_operations *fops,
+ void *data, const struct file_operations *fops,
struct dentry **dentry_p)
{
struct dentry *dentry;
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
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 through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
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 are basically the same price... so | what's the payoff ? One lock less, where? spin_unlock in principle runs unlocked on x86 at least (except for ppro workarounds but those are/should be optional) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
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). But on x86 in either case it's a locked cycle, which is just expensive no matter which side you flip the coin... If they weren't, atomic_t wouldn't belong in the kernel at all. there's different usage patterns where either makes sense. In this case it looks just disgusting on very first sight; the atomic are used to implement a lock, and that lock itself is then implemented with a spinlock again. For me, again on first sight, the real solution appears to be to use a linux primitive for the higher level lock in the first place, instead of reimplementing your own thing with another own thing. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
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 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... You are refering to SMP, aren't you? yes. on UP neither is a locked instruction ;) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
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 exclusively to protect a int variable, an atomic_t seems to be more appropriate to me. Isn't it? sounds like it... Please, if you could, review the patches with this in mind: we aren't changing any behaviour neither creating any weird lock scheme, we are only doing two things: ... however you are NOT changing the behavior, which is EXACTLY my point; the current lock emulation behavior is wrong, all you're doing is replacing how you do the wrong thing ;) It's like having a bike with square wheels, and replacing a flat tire with one with air in, as opposed to replacing it with a round wheel... --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [PATCH 00/10] usb-serial: Switches from spin lock to atomic_t.
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 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... You're overgeneralizing. to some degree yes. Sure, a locked cycle has a certain expense. But it's a lot less than the expense of a contested spinlock. the chances that *this* spinlock ends up being contested are near zero, and.. in that scenario a locked cycle does the same thing, just in hardware. (eg the other cpu will busy wait until this locked cycle is done) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH 01/10] usb-serial: URB write locking macros.
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 AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] Make usbdevice_fs.h (again) useable from userspace
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?? --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: usb: Patch for USBDEVFS_IOCTL from 32-bit programs
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 AMD64, so Dell's tests pass on their new Xeons). So, you cannot simply to have a small shim. Instead, you have to allocate the buffer, do copy_from_user(), and then call the ioctl. But then, it would be a double-copy, when the ioctl allocates the buffer again. I tweaked this in various ways, and the patch I posted looks like the cleanest solution. But please tell me if I miss something obvious. there is one more option; allocate on the user stack space for a 64 bit struct, then copy_in_user() the fields to that and then pass the new pointer to the 64 bit struct to the ioctl. Not saying this is better or worse than what you did, it's just another option. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Re: [PATCH] Avoid to use kmalloc in usb/core/message.c
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 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
