Re: [linux-usb-devel] [PATCH 2.6.20 1/1] usb/input updated aiptek tablet driver
On Fri, 2007-03-09 at 21:44 -0500, Dmitry Torokhov wrote:
On Friday 09 March 2007 19:29, Pete Zaitcev wrote:
+/* Activity checking thread. If a sufficient period of inactivity is
detected,
+ the tablet's proximity is reset. */
+static void activity_check(unsigned long data)
+{
+ struct aiptek *aiptek = (struct aiptek *) data;
+
+ /* This timer is set *after* handling input for the table, and
+cleared *before* handling it. Am guessing that we never run
+concurrently the module code. */
+
+ /* info(aiptek: timeout proximity\n); */
+
+ /* apparently over-due. Reset the misc key, no tool, no proximity */
+ input_report_abs(aiptek-inputdev, ABS_MISC, 0);
+ input_sync(aiptek-inputdev);
+}
This concerns me a bit. I am not 100% sure that input_sync and friends
are safe to run from several CPUs. Usually, nobody is bitten by this,
because they are delivered from a single IRQ. If you start doing this
from a timer, it's not longer true. Dmitry must bless this practice
(cc-ed). Perhas you want a spinlock here.
I want to fix locking in input handlers so concurrent execution of
-event() methods is not an issue. However there will be a question
of correctness of the sequence in what events are delivered so some
kind of locking in drivers themselves still may make sense.
The timer is removed before the routine that handles the tablet data
(aiptek_irq) starts sending its own data with input_sync and friends. So
this should not produce any problem.
I will change the del_timer to del_timer_sync, to remove the race where
the timer´s activity is running while the timer is being removed.
Does that sound reasonable?
René
###
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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 2.6.20 1/1] usb/input updated aiptek tablet driver
On Sat, 24 Mar 2007 17:23:55 +0100, René van Paassen [EMAIL PROTECTED] wrote: I will change the del_timer to del_timer_sync, to remove the race where the timer´s activity is running while the timer is being removed. Does that sound reasonable? Yes, it's a good idea, however this is not quite what I was concerned about. For a timer, it's possible to run on one CPU while a URB callback is being delivered on another CPU. Even if Dmitry does everything right and provides a perfect exclusion inside input_report(), you still may end with input events interleaving without some kind of exclusion in the driver. This is why I asked if aiptek can call input_report_abs() with interrupts closed (which happens if you bracket them with spin_lock_irqsave() in your timer routine). -- Pete - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Device failing to enumerate with EHCI
Am Freitag, 23. März 2007 20:08 schrieb David Brownell: ... no, that's a special case. Oddball devices that implement halt status on ep0 must allow clear-halt requests for it too. See 8.5.3.4 and (especially) the end of 9.4.5 ... So not clearing and retrying is a bug? Linux should handle such oddball devices. Is it clear that this is one of those cases? How do I find out? Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Device failing to enumerate with EHCI
Am Samstag, 24. März 2007 04:21 schrieb Alan Stern: I don't see any easy way to tell. The spec doesn't offer any good way to tell the difference between one type of stall and the other. In fact, the only way seems to be to send another request that _should_ always succeed and see whether it does. So why not simply clear the halt anyway? If it doesn't work, no harm is done. Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Question about usb-serial port registration
Am Samstag, 24. März 2007 04:30 schrieb Alan Stern: Regular files work like that. If a program has a file named foo open when you do rm foo, the open file reference won't prevent you from creating a new file named foo in the same directory. There will be no conflict or confusion between the two files. The kernel no longer deals with device names. With ordinary files, the kernel would violate the standard if it reused an inode number while a file is still open. Regards Oliver - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] [PATCH 0/2] [SERIAL] [USB] fixed to skip NULL entry in struct serial usb_serial_port.
Hi, When I boot using linux-2.6.21-rc4 on ThinkPad T41 with pl2303 USB serial device plugged in, the kernel crashes. The reason is struct usb_serial_port is referenced without checking whether it is NULL or not. Regards, -- Noriaki TAKAMIYA - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] [PATCH 1/2] [USB] [PL2303]: fixed to skip NULL entry in pl2303_shutdown.
Hi,
While booting, this entry is set to NULL in destroy_serial(),
but serial-port is referred again in pl2303_shutdown() via
serial-type-shutdown.
---
drivers/usb/serial/pl2303.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 83dfae9..d631f8c 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -905,6 +905,8 @@ static void pl2303_shutdown(struct usb_s
dbg(%s, __FUNCTION__);
for (i = 0; i serial-num_ports; ++i) {
+ if (!serial-port[i])
+ continue;
priv = usb_get_serial_port_data(serial-port[i]);
if (priv) {
pl2303_buf_free(priv-buf);
--
1.4.4
--
Noriaki TAKAMIYA
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] [PATCH 2/2] [USB] [SERIAL]: fixed to skip NULL port entry in struct usb_serial_port.
Hi,
This patch fixes to skip serial-port[i] if it is set NULL.
---
include/linux/usb/serial.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index 32acbae..85ed5ef 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -99,7 +99,10 @@ struct usb_serial_port {
/* get and set the port private data pointer helper functions */
static inline void *usb_get_serial_port_data (struct usb_serial_port *port)
{
- return dev_get_drvdata(port-dev);
+ if (port)
+ return dev_get_drvdata(port-dev);
+ else
+ return NULL;
}
static inline void usb_set_serial_port_data (struct usb_serial_port *port,
void *data)
--
1.4.4
--
Noriaki TAKAMIYA
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] (usagi-core 32633) [PATCH 1/2] [USB] [PL2303]: fixed to skip NULL entry in pl2303_shutdown.
Sorry for resending.
While booting, this entry is set to NULL in destroy_serial(),
but serial-port is referred again in pl2303_shutdown() via
serial-type-shutdown.
Signed-off-by: Noriaki TAKAMIYA [EMAIL PROTECTED]
---
drivers/usb/serial/pl2303.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 83dfae9..d631f8c 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -905,6 +905,8 @@ static void pl2303_shutdown(struct usb_s
dbg(%s, __FUNCTION__);
for (i = 0; i serial-num_ports; ++i) {
+ if (!serial-port[i])
+ continue;
priv = usb_get_serial_port_data(serial-port[i]);
if (priv) {
pl2303_buf_free(priv-buf);
--
1.4.4
--
Noriaki TAKAMIYA
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] (usagi-core 32634) [PATCH 2/2] [USB] [SERIAL]: fixed to skip NULL port entry in struct usb_serial_port.
Sorry for resending.
Hi,
This patch fixes to skip serial-port[i] if it is set NULL.
Signed-off-by: Noriaki TAKAMIYA [EMAIL PROTECTED]
---
include/linux/usb/serial.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index 32acbae..85ed5ef 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -99,7 +99,10 @@ struct usb_serial_port {
/* get and set the port private data pointer helper functions */
static inline void *usb_get_serial_port_data (struct usb_serial_port *port)
{
- return dev_get_drvdata(port-dev);
+ if (port)
+ return dev_get_drvdata(port-dev);
+ else
+ return NULL;
}
static inline void usb_set_serial_port_data (struct usb_serial_port *port,
void *data)
--
1.4.4
--
Noriaki TAKAMIYA
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] (usagi-core 32633) [PATCH 1/2] [USB] [PL2303]: fixed to skip NULL entry in pl2303_shutdown.
Sorry for resending
Hi,
While booting, this entry is set to NULL in destroy_serial(),
but serial-port is referred again in pl2303_shutdown() via
serial-type-shutdown.
---
drivers/usb/serial/pl2303.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 83dfae9..d631f8c 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -905,6 +905,8 @@ static void pl2303_shutdown(struct usb_s
dbg(%s, __FUNCTION__);
for (i = 0; i serial-num_ports; ++i) {
+ if (!serial-port[i])
+ continue;
priv = usb_get_serial_port_data(serial-port[i]);
if (priv) {
pl2303_buf_free(priv-buf);
--
1.4.4
--
Noriaki TAKAMIYA
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
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] [5/5] 2.6.21-rc4: known regressions (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20. 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: Oops when changing DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 Submitter : CIJOML [EMAIL PROTECTED] Status : unknown Subject: USB: iPod doesn't work References : http://lkml.org/lkml/2007/3/21/320 Submitter : Tino Keitel [EMAIL PROTECTED] Handled-By : Oliver Neukum [EMAIL PROTECTED] Status : problem is being debuggged Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Takashi Iwai [EMAIL PROTECTED] Status : problem is being debugged Subject: forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins [EMAIL PROTECTED] Handled-By : Ayaz Abdulla [EMAIL PROTECTED] Patch : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Status : patch available - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Device failing to enumerate with EHCI
On Sat, 24 Mar 2007, Oliver Neukum wrote: Am Samstag, 24. März 2007 04:21 schrieb Alan Stern: I don't see any easy way to tell. The spec doesn't offer any good way to tell the difference between one type of stall and the other. In fact, the only way seems to be to send another request that _should_ always succeed and see whether it does. So why not simply clear the halt anyway? If it doesn't work, no harm is done. Don't be so sure. Clearing a halt on endpoint 0 is sufficiently unusual that I bet some devices will fail to handle it and will crash. If you want to test what happens with this particular device, go right ahead. Maybe it will fix the failure to enumerate with EHCI. But in general my feeling is that we should leave well enough alone. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] Device failing to enumerate with EHCI
On Saturday 24 March 2007 11:58 am, Oliver Neukum wrote: Am Freitag, 23. März 2007 20:08 schrieb David Brownell: ... no, that's a special case. Oddball devices that implement halt status on ep0 must allow clear-halt requests for it too. See 8.5.3.4 and (especially) the end of 9.4.5 ... So not clearing and retrying is a bug? Retrying wouldn't do much good now would it? I'd say that devices needing such a clear-halt are worth a quirk flag. This is a quirk that should (only?) be autodetected. Linux should handle such oddball devices. Is it clear that this is one of those cases? How do I find out? If the quirk is set, you have the answer. :) I suggest that when ep0 stalls you look at its endpoint status to see if the HALT bit is set ... if it is, set the quirk flag. - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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 0/2] [SERIAL] [USB] fixed to skip NULL entry in struct serial usb_serial_port.
On Sun, Mar 25, 2007 at 12:52:27AM +0900, Noriaki TAKAMIYA wrote: Hi, When I boot using linux-2.6.21-rc4 on ThinkPad T41 with pl2303 USB serial device plugged in, the kernel crashes. The reason is struct usb_serial_port is referenced without checking whether it is NULL or not. This should already be fixed in the -git snapshots that have come out after 2.6.21-rc4. Can you test them to verify this? thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ 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] (usagi-core 32638) Re: [PATCH 0/2] [SERIAL] [USB] fixed to skip NULL entry in struct serial usb_serial_port.
Hi, Sat, 24 Mar 2007 14:22:53 -0700 [Subject: (usagi-core 32638) Re: [linux-usb-devel] [PATCH 0/2] [SERIAL] [USB] fixed to skip NULL entry in struct serial usb_serial_port.] Greg KH [EMAIL PROTECTED] wrote... This should already be fixed in the -git snapshots that have come out after 2.6.21-rc4. Can you test them to verify this? Yes, this problem was already fixed. Thanks. -- Noriaki TAKAMIYA - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
