Thanks for the comments Alexey.
The whitespaces came from the diff. I the only switch what I have used it -u.
About the VENDOR_ID and PRODUCT_ID, I have looked at the code of
stv680.c that was in 2.6.11.11 and there the variables were casted.
> @@ -1375,9 +1383,14 @@
> (le16_to_cpu(dev
On Thursday 02 June 2005 23:13, Stéphane VOLTZ wrote:
> Dmitry Torokhov a écrit :
>
> >On 6/2/05, Stéphane VOLTZ <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Hello,
> >>
> >> I have removed these superfluous attributes and unused MISC things,
> >>added the dev.dev field.
> >>The gimp is working fin
On Thu, Jun 02, 2005 at 09:43:46PM -0400, Stuart MacDonald wrote:
> The serial sub-drivers (whiteheat.c is one) have to call
> tty_flip_buffer_push() somehow. Queueing the task means it runs from
> (timer) interrupt context. Calling it directly means a) low_latency is
> set; runs from sub-driver rx
On Fri, Jun 03, 2005 at 11:20:33AM +0800, Enzo Chen (?h) wrote:
> Hi all,
>
> Recently, we are developing USB driver for our products, and we found the
> "usb_unlink_urb" function not work.
>
> The S/W platform is Fedora Core 2 with kernel version 2.6.5-1, when we open
> our USB devic
On Fri, Jun 03, 2005 at 11:20:26AM +0530, Annamalai Prakash wrote:
>Thanks for your reply ... I am thinking to write my own Bluetooth Stack
Oh no, Linux already has about 5 of them at my last count... Why write
another one? Seriously, it's not a trivial task.
> .. thats why,
> I am trying .
Adam Kropelin wrote:
Alan Stern wrote:
On Thu, 2 Jun 2005, Adam Kropelin wrote:
It would certainly help to know exactly where the blockage occurs. Is
it in the HID queuing code, in the HCD (unlikely), or in the UPS
device? Suitable debugging statements ought to settle that pretty
easily.
On Sun, May 29, 2005 at 08:12:35PM -0500, Jeremy S. Viehland wrote:
> I am posting this because, when I looked for it, I could not find it.
>
> The IBM Ultraport camera driver for linux kernel version 2.6.10
> (ultracam module) is now working for me, after quite a bit of
> modification.
Care to
Dmitry Torokhov a écrit :
On 6/2/05, Stéphane VOLTZ <[EMAIL PROTECTED]> wrote:
Hello,
I have removed these superfluous attributes and unused MISC things,
added the dev.dev field.
The gimp is working fine with this version of the module. Patch is attached.
Hi Stephane,
It looks li
On Thu, 2 Jun 2005 21:43:46 -0400, "Stuart MacDonald" <[EMAIL PROTECTED]> wrote:
> So, flush_to_ldisc() is running in interrupt context. It can call back
> into usbserial.c in a number of ways, specifically serial_throttle.
> Which tries to acquire a semaphore, which sometimes sleeps, resulting
>
Hi all,
Recently, we are developing USB driver for our products, and we found the
"usb_unlink_urb" function not work.
The S/W platform is Fedora Core 2 with kernel version 2.6.5-1, when we open
our USB device node, we submit the read_urb,
and it is expected to be unlinked when the user
The serial sub-drivers (whiteheat.c is one) have to call
tty_flip_buffer_push() somehow. Queueing the task means it runs from
(timer) interrupt context. Calling it directly means a) low_latency is
set; runs from sub-driver rx-side interrupt context or b) low_latency
is *not* set and it's queued, se
Hi,
What is the status of usbnet support for the ASIX ax88178 usb2/gigabit
ethernet chip? I thought I remembered seeing support for it in the code
earlier, but I don't see it in 2.6.12-rc5-mm2 now and I didn't find
anything in a mail archive search.
I have some ax88178 adapters on the way a
Alan Stern wrote:
On Thu, 2 Jun 2005, Adam Kropelin wrote:
It would certainly help to know exactly where the blockage occurs.
Is
it in the HID queuing code, in the HCD (unlikely), or in the UPS
device? Suitable debugging statements ought to settle that pretty
easily.
Yes, that's a crucial de
Hello all,
I have the strangest problem with the additional USB ports in the ezDock
docking station of my Acer Travelmate 8100 notebook. The docking
station is somewhat exotic in that it connects via PCI Express to the
notebook and attaches the additional ports, realized by PCI-connected
VIA 1.1 a
Hi folks,,
extract() and implement() are bit field manipulation routines.
They mangle "n" bits starting at "offset" index into the bit field.
Since this is USB, the byte array is little endian.
Big endian machines (e.g. parisc, mips) should only need to
byte swap the value.
extract() and implement
On Thu, Jun 02, 2005 at 05:16:34PM -0400, C. Adam Oldham wrote:
> Hi,
>
> Attached the the proper patchfile to fix the race condition with
> checking the write status.
>
> Signed-off-by: Adam Oldham <[EMAIL PROTECTED]>
>
> I guess if you're asking me for the Changelog text, maybe:
> <[EMAIL PROT
Hi,
Attached the the proper patchfile to fix the race condition with
checking the write status.
Signed-off-by: Adam Oldham <[EMAIL PROTECTED]>
I guess if you're asking me for the Changelog text, maybe:
<[EMAIL PROTECTED]>
[PATCH] [usblp.c] Initialize status fields in the read and write u
On 6/2/05, Stéphane VOLTZ <[EMAIL PROTECTED]> wrote:
>Hello,
>
> I have removed these superfluous attributes and unused MISC things,
> added the dev.dev field.
> The gimp is working fine with this version of the module. Patch is attached.
>
Hi Stephane,
It looks like acecad_features struct
Dmitry Torokhov a écrit :
Hi Edouard,
On 6/1/05, Edouard TISSERANT <[EMAIL PROTECTED]> wrote:
Hi all.
Patch should be now OK.
It should fit to last Dimitry's requests.
Yes, it is much better now. I still have couple of concerns though:
+ acecad->dev.absmin[ABS_MISC] = 0
On Thu, 2 Jun 2005, Adam Kropelin wrote:
> > It would certainly help to know exactly where the blockage occurs. Is it
> > in the HID queuing code, in the HCD (unlikely), or in the UPS device?
> > Suitable debugging statements ought to settle that pretty easily.
>
> Yes, that's a crucial detail
On Thu, 2 Jun 2005, Matthias Urlichs wrote:
> Hi,
>
> This happened with 2.6.12-rc5-mm1.
> One side effect was that eth0 locked up..?
>
>
> scheduling while atomic: khubd/0x0001/4258
> [] schedule+0x5cc/0x5e0
> [] invalidate_inode_buffers+0xc/0x70
> [] __wake_up+0x14/0x20
> [] __down+0x7b/0
Hi,
This happened with 2.6.12-rc5-mm1.
One side effect was that eth0 locked up..?
scheduling while atomic: khubd/0x0001/4258
[] schedule+0x5cc/0x5e0
[] invalidate_inode_buffers+0xc/0x70
[] __wake_up+0x14/0x20
[] __down+0x7b/0xf0
[] default_wake_function+0x0/0x20
[] simple_unlink+0x3b/0x50
[]
On Thursday 02 June 2005 19:35, Kiril Jovchev wrote:
> So now I'm sending the patch again for 2.6.11.11 kernel what is latest stable.
You're lucky it applies cleanly against 2.6.12-rc5-whatever. ;-)
There is no need to split the patch into two ones. Next time CC
[EMAIL PROTECTED] Add "-p" to you
Greg, as per David's recommendation, could we get this small patch expedited
for 2.6.12 final?
Problem: Failed to recognize Zaurus SL 6000 as usbnet device. Hasn't worked
since 2.6.10.
Fix: In 2.6.12-rc5 drivers/usb/net/usbnet.c
Check two GUIDs not just one.
Submitted-by: Gerald Skerb
On Thu, Jun 02, 2005 at 10:07:12AM -0400, Alan Stern wrote:
> On Wed, 1 Jun 2005, Adam Kropelin wrote:
>
> > Poking thru hid-core.c I did see a number of things that look buggy in
> > the queuing logic. For example, this bit in the control pipe completion
> > handler...
>
> It would certainly hel
On Wed, 1 Jun 2005, Adam Kropelin wrote:
> Poking thru hid-core.c I did see a number of things that look buggy in
> the queuing logic. For example, this bit in the control pipe completion
> handler...
> ...which appears to reset the queue on successful transfers rather than
> continuing on with s
On Wed, 1 Jun 2005, Oliver Neukum wrote:
> > It's not so easy to synchronize operations on an attribute with driver
> > operations if the driver doesn't own the attribute's kobject. In this
>
> Are you suggesting that kobjects should have slaves whose refcounts
> they control?
No, not necessa
On Thursday 02 June 2005 4:45 am, Ian Abbott wrote:
> On 31/05/2005 18:16, David Brownell wrote:
> >
> > My advice continues to be to strongly avoid using bulk queueing
> > on 2.4 kernels ... on 2.6 it's even in the regression test suite,
> > but it took some time for it to be reliable even there.
On 31/05/2005 18:16, David Brownell wrote:
On Tuesday 31 May 2005 9:42 am, Stuart MacDonald wrote:
I'm updating our WhiteHEAT driver, and would like to have URB queueing
working.
My advice continues to be to strongly avoid using bulk queueing
on 2.4 kernels ... on 2.6 it's even in the regres
Hi,
The ftdi_sio driver receives up to 496 bytes of data at a time (512 byte
transfer minus 16 status bytes) and this can cause data to be lost in
the tty line discipline handling, even if hardware flow control is enabled.
The attached patch, originally by Daniel Smertnig with some changes by
mys
30 matches
Mail list logo
