On Fri, 10 Aug 2007, jidong xiao wrote:
> Here are the piece of code from 2.6.22.1,
>
>2817 static int hub_thread(void *__unused)
>2818 {
>2819 do {
>2820 hub_events();
>2821 wait_event_interruptible(khubd_wait,
>2822
Here are the piece of code from 2.6.22.1,
2817 static int hub_thread(void *__unused)
2818 {
2819 do {
2820 hub_events();
2821 wait_event_interruptible(khubd_wait,
2822 !list_empty(&hub_event_list) ||
2823
On Friday 03 August 2007, Lorenzo T. Flores wrote:
>
> Anyways, for a while now, I've been trying to get the ethernet gadget
> driver working on a Cirrus EP9315A development board contains the
> Phillips ISP1581 usb device controller.
There is no drivers/usb/gadget/isp1581.c driver ...
> The
I origionally posted this on the -users forum, but Alan Stern mentioned
I should post this here:
Hello everyone,
Hi everyone not sure if others have already addressed this, or what you
all think...
Anyways, for a while now, I've been trying to get the ethernet gadget
driver working on a Cirrus
On Wed, 4 Jul 2007, jidong xiao wrote:
> Still consider following piece of code, I see there is a change in
> this part of code,here showed the same part of code but came from
> different kernel version,one is sampled from kernel 2.6.10,while
> another is sampled from kernel 2.6.21.
>
> inside hu
Still consider following piece of code, I see there is a change in
this part of code,here showed the same part of code but came from
different kernel version,one is sampled from kernel 2.6.10,while
another is sampled from kernel 2.6.21.
inside hub_events() sampled from drivers/usb/core/hub.c, 2.6.
On 7/3/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Jul 2007, Felipe Balbi wrote:
>
> > Hi Allan,
> >
> > let me get this same thread to ask you the following
>
> > How could I force my usb host controller to re-enumerate everything
> > attached on the bus through userspace?? would it be s
On Tue, 3 Jul 2007, Felipe Balbi wrote:
> Hi Allan,
>
> let me get this same thread to ask you the following
> How could I force my usb host controller to re-enumerate everything
> attached on the bus through userspace?? would it be some sort of
> control message???
The easiest way is to unbind
Hi Allan,
let me get this same thread to ask you the following
On 7/3/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Jul 2007, jidong xiao wrote:
>
> > What's the difference between event_bits and change_bits?
> > I just cannot understand why we need two variables.
> >
> >
> > 188 stru
On Tue, 3 Jul 2007, jidong xiao wrote:
> What's the difference between event_bits and change_bits?
> I just cannot understand why we need two variables.
>
>
> 188 struct usb_hub {
> ...
> 205 unsigned long event_bits[1]; /* status
> change bitmask */
> 206
What's the difference between event_bits and change_bits?
I just cannot understand why we need two variables.
188 struct usb_hub {
...
205 unsigned long event_bits[1]; /* status
change bitmask */
206 unsigned long change_bits[1]; /* ports with
Am Freitag, 29. Juni 2007 schrieb David Brownell:
> On Friday 29 June 2007, Oliver Neukum wrote:
> > Hi,
> >
> > I am trying to calculate worst cases memory requirements of EHCI.
> > For bulk transfers it seems to me that you need size/16384 (rounded up)
> > qtd and one qh. Is it really that easy?
On Friday 29 June 2007, Oliver Neukum wrote:
> Hi,
>
> I am trying to calculate worst cases memory requirements of EHCI.
> For bulk transfers it seems to me that you need size/16384 (rounded up)
> qtd and one qh. Is it really that easy?
ISTR, yes. And interrupt transfers are the same.
> What ab
Hi,
I am trying to calculate worst cases memory requirements of EHCI.
For bulk transfers it seems to me that you need size/16384 (rounded up)
qtd and one qh. Is it really that easy?
What about the other transfer types?
TIA
Oliver
-
On Thursday 28 June 2007, Oliver Neukum wrote:
> Am Donnerstag, 28. Juni 2007 schrieb David Brownell:
> > On Thursday 28 June 2007, Oliver Neukum wrote:
> > > Hi,
> > >
> > > am I seeing this correctly that struct ed is allocated the first time an
> > > URB
> > > is submitted for the ed's endpoin
Am Donnerstag, 28. Juni 2007 schrieb David Brownell:
> On Thursday 28 June 2007, Oliver Neukum wrote:
> > Hi,
> >
> > am I seeing this correctly that struct ed is allocated the first time an URB
> > is submitted for the ed's endpoint and is freed when the endpoint is
> > disabled?
>
> That's the
On Thursday 28 June 2007, Oliver Neukum wrote:
> Hi,
>
> am I seeing this correctly that struct ed is allocated the first time an URB
> is submitted for the ed's endpoint and is freed when the endpoint is disabled?
That's the idea.
>
> Regards
> Oliver
>
---
Hi,
am I seeing this correctly that struct ed is allocated the first time an URB
is submitted for the ed's endpoint and is freed when the endpoint is disabled?
Regards
Oliver
-
This SF.net email is sp
Am Mittwoch, 27. Juni 2007 schrieb jidong xiao:
> What's the difference between configuration and setting?Can anybody
> show me any real examples, thank you.
device -> configuration -> interface -> setting
A device has configurations. A configuration determines which interfaces
are available. A c
What's the difference between configuration and setting?Can anybody
show me any real examples, thank you.
Regards
Jason Xiao
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 exp
Calm down.
We should discuss this problem in a rational way. I believe there
should be more stories behind this mail. Even though I am not quite
clear about what happened before, but I guess probably you argued on
this some time back. So what are the current status?
Regards
Jason Xiao
On 6/20/07,
Am Dienstag, 19. Juni 2007 schrieb Pete Zaitcev:
> On Tue, 19 Jun 2007 09:26:15 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > The main problem is that the URB does not have an s/g list. If it
> > > did, the whole library would be unnecessary. Nonetheless, we still
> >
> > And that from
On Tue, 19 Jun 2007 09:26:15 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > The main problem is that the URB does not have an s/g list. If it
> > did, the whole library would be unnecessary. Nonetheless, we still
>
> And that from the man who complained about 24 more bytes in struct urb ;-)
On Tuesday 22 May 2007, Alan Stern wrote:
> On Tue, 22 May 2007, David Brownell wrote:
>
> > > > 2) What happens if the device terminates the transfer during the 4KB
> > > > (after say 3700 bytes received, with a short packet)?
> > > >
> > > > Thus:
> > > > urb->transfer_buffer_length = 4096
>
On Tue, 22 May 2007, David Brownell wrote:
> > > 2) What happens if the device terminates the transfer during the 4KB
> > > (after say 3700 bytes received, with a short packet)?
> > >
> > > Thus:
> > > urb->transfer_buffer_length = 4096
> > > urb->actual_length = 3700
> > >
> > > I be
On Tuesday 22 May 2007, Alan Stern wrote:
> On Tue, 22 May 2007, Curran, Dominic wrote:
>
> >
> > Lets say the Hosts Mass Storage driver wants to READ 12K:
> >
> > I believe that the Host Controller driver (e.g. ehci_hcd) might see
> > something like this coming from usbcore:
> >
> > 1) BULK OU
On Tue, 22 May 2007, Curran, Dominic wrote:
> Hi
> I have two questions regarding short transfers.
> My questions are best illustrated by a scenario:
>
> Lets say the Hosts Mass Storage driver wants to READ 12K:
>
> I believe that the Host Controller driver (e.g. ehci_hcd) might see
> something
Hi
I have two questions regarding short transfers.
My questions are best illustrated by a scenario:
Lets say the Hosts Mass Storage driver wants to READ 12K:
I believe that the Host Controller driver (e.g. ehci_hcd) might see
something like this coming from usbcore:
1) BULK OUT urb (31 bytes) [
On Thursday 17 May 2007, Tzachi Perelstein wrote:
> Besides arguing with me if I have a buggy PCI or not, you couldn't
> explain _why_ this is the appropriate handling.
I was pointing out to you that there's nothing particularly wrong
about it. And it has the virtues of being straightforward ...
David Brownell wrote:
> On Tuesday 15 May 2007, Tzachi Perelstein wrote:
>> David Brownell wrote:
>>> On Sunday 13 May 2007, Tzachi Perelstein wrote:
Hello,
I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
a PCI/PCIE interfaces as well as an integrated USB c
On Tuesday 15 May 2007, Tzachi Perelstein wrote:
> David Brownell wrote:
> > On Sunday 13 May 2007, Tzachi Perelstein wrote:
> >> Hello,
> >>
> >> I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
> >> a PCI/PCIE interfaces as well as an integrated USB controller.
> >>
> >> Whil
David Brownell wrote:
> On Sunday 13 May 2007, Tzachi Perelstein wrote:
>> Hello,
>>
>> I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
>> a PCI/PCIE interfaces as well as an integrated USB controller.
>>
>> While looking at ehci-hcd.c it looks like there's some kind of depend
On Sunday 13 May 2007, Tzachi Perelstein wrote:
> Hello,
>
> I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
> a PCI/PCIE interfaces as well as an integrated USB controller.
>
> While looking at ehci-hcd.c it looks like there's some kind of dependency
> between PCI_DRIVER an
Hello,
I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has
a PCI/PCIE interfaces as well as an integrated USB controller.
While looking at ehci-hcd.c it looks like there's some kind of dependency
between PCI_DRIVER and PLATFORM_DRIVER. I saw some previous threads
about the ehci-
> >
> > The buffer is created in usbtest.c:iso_alloc_urb(), at the point where it
> > calls usb_buffer_alloc().
>
> Actually cant i fill this buffer in user space?
No.
> it is more logic to fill the buffer in the user-space (testusb.c)
> then let the usbtest.c module send the iso-packet that c
On 4/8/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sun, 8 Apr 2007, nesta wrote:
>
> > hello guys,
> > i want to test the iso packets written by the host so
> > i should write : ./test.sh -t15
> > everything is fine uptill now but my question is:
> >
> > where is the buffer that is filled by the
On Sun, 8 Apr 2007, nesta wrote:
> hello guys,
> i want to test the iso packets written by the host so
> i should write : ./test.sh -t15
> everything is fine uptill now but my question is:
>
> where is the buffer that is filled by the iso-packets?
>
> i have searched for it in testusb.c and usb
hello guys,
i want to test the iso packets written by the host so
i should write : ./test.sh -t15
everything is fine uptill now but my question is:
where is the buffer that is filled by the iso-packets?
i have searched for it in testusb.c and usbtest.c but i cant find it?
can anyone tell me ple
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
On Fri, Mar 23, 2007 at 01:30:45PM -0700, John wrote:
> > Those aren't serial numbers in the USB sense.
>
> > Consider any FT 232R device, which is assigned
> > one from the factory
>
> I see. So, aparently, Till wanted to query
> for the manufacturer's assigned serial number
> and somehow rememb
On Fri, 23 Mar 2007, Greg KH wrote:
> > I don't buy the argument about needing to keep the number in use merely
> > because the device node is still open. Once the node has been
> > unregistered it is no longer visible to userspace. Only the existing open
> > file references can be used, and a n
On Fri, Mar 23, 2007 at 11:30:16PM -0400, Alan Stern wrote:
> On Fri, 23 Mar 2007, Greg KH wrote:
>
> > On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
> > > Here two solutions are possible:
> > > 1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
> > > reserved until all files are closed
On Fri, 23 Mar 2007, Greg KH wrote:
> On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
> > Here two solutions are possible:
> > 1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
> > reserved until all files are closed.
> > This is what the current code attempts to do.
> > But this means t
On Fri, Mar 23, 2007 at 07:18:50PM -0700, John wrote:
>
> --- Greg KH <[EMAIL PROTECTED]> wrote:
>
> > As for applications that foolishly use ttyUSB0 only,
> > well, they kind of deserve the breakage.
> > It is pretty trivial to work around that issue
> > with udev if they want to (and it's rec
--- Greg KH <[EMAIL PROTECTED]> wrote:
> As for applications that foolishly use ttyUSB0 only,
> well, they kind of deserve the breakage.
> It is pretty trivial to work around that issue
> with udev if they want to (and it's recommended
> that they fix it that way...)
In this case somebody sho
On Fri, Mar 23, 2007 at 01:35:44PM -0700, John wrote:
> > I say #1 as I implemented it :)
> >
> > If userspace still has the device node open, then we
> > need to keep the
> > number still in use.
>
> OK, if this behavior is by design
> (and it is hard to tell what is by design
> and what is by a
> I say #1 as I implemented it :)
>
> If userspace still has the device node open, then we
> need to keep the
> number still in use.
OK, if this behavior is by design
(and it is hard to tell what is by design
and what is by accident when you look at a code
without any documentation),
then I will
Am Freitag, 23. März 2007 21:18 schrieb David Brownell:
> > > > It seems to me that if we cannot guarantee that
> > > > the devices are identical, we must make sure they
> > > > have different numbers.
>
> That means the numbers "x" in ttyUSBx will almost never
> be re-used. To me that sounds lik
> Those aren't serial numbers in the USB sense.
> Consider any FT 232R device, which is assigned
> one from the factory
I see. So, aparently, Till wanted to query
for the manufacturer's assigned serial number
and somehow remember which ttyUSBx port
we assigned to it and assign the same number
nex
On Fri, Mar 23, 2007 at 08:42:28PM +0100, Till Harbaum / Lists wrote:
> Hi,
>
> Am Freitag, 23. M?rz 2007 20:36 schrieb John:
> > It seems to me that if we cannot guarantee that
> > the devices are identical, we must make sure they
> > have different numbers.
> What about devices that have serial
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
> Here two solutions are possible:
> 1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
> reserved until all files are closed.
> This is what the current code attempts to do.
> But this means that if the same device is re-plugged,
> it will b
> > > It seems to me that if we cannot guarantee that
> > > the devices are identical, we must make sure they
> > > have different numbers.
That means the numbers "x" in ttyUSBx will almost never
be re-used. To me that sounds like something that will
break lots of userspace code.
> > What about
Hi,
Am Freitag, 23. März 2007 20:58 schrieb John:
> I am not sure what you mean as
> "devices that have serial numbers?"
USB devices can include a unique serial number allowing even devices
of the same kind to be distinguished.
Thus you would know that exactly the same device has been plugged in.
> > It seems to me that if we cannot guarantee that
> > the devices are identical, we must make sure they
> > have different numbers.
> What about devices that have serial numbers?
> Wouldn't it at least
> be a good idea to make their file usage persistant?
I am not sure what you mean as
"devices
Hi,
Am Freitag, 23. März 2007 20:36 schrieb John:
> It seems to me that if we cannot guarantee that
> the devices are identical, we must make sure they
> have different numbers.
What about devices that have serial numbers? Wouldn't it at least
be a good idea to make their file usage persistant?
T
Hi,
Since last December me and Oliver are trying to
fix a number of problems in usb-serial.c.
Most of them happen when devices are plugged
and unplugged and files are opened and closed
in various orders.
usb-serial.c registers new tty ports by calling
device_register from usb_serial_probe routine,
Am Donnerstag, 15. März 2007 17:29 schrieb David Howells:
> How about the following:
>
>
> INTERRUPT HANDLING
> --
>
> Execution of the interrupt handler chain for an interrupt not bound to a CPU
> is bounded by a lock/unlock at either side. Furthermore, recurrence of that
> in
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> + (*) entering and returning from interrupt handlers implies a full barrier
That shouldn't really be under the "MISCELLANEOUS FUNCTIONS" subheading as
it's not precisely describing a callable function that has barrier effects.
Hmmm... also it isn't quit
Am Donnerstag, 15. März 2007 10:39 schrieb Robert Marquardt:
> Oliver Neukum wrote:
>
> >>> OK, thanks. I am relieved.
> >>> Should I add a section concerning this to Documentation?
> >> Is that a trick question? :-)
> >
> > No.
>
> Your question if it should be documented bears itself the answ
Oliver Neukum wrote:
>>> OK, thanks. I am relieved.
>>> Should I add a section concerning this to Documentation?
>> Is that a trick question? :-)
>
> No.
Your question if it should be documented bears itself the answer.
Of course!
If an expert has doubts then lesser experts and common folk do n
Am Donnerstag, 15. März 2007 09:57 schrieb Robert Marquardt:
> Oliver Neukum wrote:
>
> > OK, thanks. I am relieved.
> > Should I add a section concerning this to Documentation?
>
> Is that a trick question? :-)
No.
Regards
Oliver
---
Oliver Neukum wrote:
> OK, thanks. I am relieved.
> Should I add a section concerning this to Documentation?
Is that a trick question? :-)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay
Am Donnerstag, 15. März 2007 09:16 schrieb Greg KH:
> On Wed, Mar 14, 2007 at 08:44:22PM +0100, Oliver Neukum wrote:
> > It is called in interrupt and uses no locking. What happens if the next
> > irq is processed on another cpu? Is that cpu guaranteed to see the updates
> > to the incremented var
Am Mittwoch, 14. März 2007 23:44 schrieb David Howells:
> Pete Zaitcev <[EMAIL PROTECTED]> wrote:
>
> > I think he is concerned about CPU A executing an interrupt handler, its
> > stores getting stuck in its store buffer or its write-back cache, the IRQ
> > finished, IRQ get migrated to CPU B, CPU
Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> I think he is concerned about CPU A executing an interrupt handler, its
> stores getting stuck in its store buffer or its write-back cache, the IRQ
> finished, IRQ get migrated to CPU B, CPU B taking next interrupt and seeing
> old RAM state. I don't see
Am Mittwoch, 14. März 2007 22:21 schrieb Pete Zaitcev:
> On Wed, 14 Mar 2007 20:59:29 +, David Howells <[EMAIL PROTECTED]> wrote:
>
> > Oliver Neukum <[EMAIL PROTECTED]> wrote:
> >
> > > It is called in interrupt and uses no locking. What happens if the next
> > > irq is processed on another
On Wed, 14 Mar 2007 20:59:29 +, David Howells <[EMAIL PROTECTED]> wrote:
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > It is called in interrupt and uses no locking. What happens if the next
> > irq is processed on another cpu? Is that cpu guaranteed to see the updates
> > to the increment
Am Mittwoch, 14. März 2007 21:59 schrieben Sie:
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > It is called in interrupt and uses no locking. What happens if the next
> > irq is processed on another cpu? Is that cpu guaranteed to see the updates
> > to the incremented variables?
>
> I thought t
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> It is called in interrupt and uses no locking. What happens if the next
> irq is processed on another cpu? Is that cpu guaranteed to see the updates
> to the incremented variables?
I thought that possibility was prevented by IRQ_INPROGRESS.
David
-
Hi,
I am looking at this code:
if (new_msr &
(MOS_MSR_DELTA_CTS | MOS_MSR_DELTA_DSR | MOS_MSR_DELTA_RI |
MOS_MSR_DELTA_CD)) {
icount = &mos7840_port->icount;
/* update input line counters */
if (new_msr & MOS_MSR_DE
On Wed, 14 Mar 2007, Oliver Neukum wrote:
> Hi,
>
> I am looking at this code:
>
> if (new_msr &
> (MOS_MSR_DELTA_CTS | MOS_MSR_DELTA_DSR | MOS_MSR_DELTA_RI |
>MOS_MSR_DELTA_CD)) {
> icount = &mos7840_port->icount;
>
> /* update input line
Hi,
I am looking at this code:
if (new_msr &
(MOS_MSR_DELTA_CTS | MOS_MSR_DELTA_DSR | MOS_MSR_DELTA_RI |
MOS_MSR_DELTA_CD)) {
icount = &mos7840_port->icount;
/* update input line counters */
if (new_msr & MOS_MSR_DE
On Saturday 10 March 2007, Adam Kropelin wrote:
>Jiri Kosina wrote:
>> I am still however pretty far from being convinced that this will make
>> your application work. But as I absolutely don't know what your
>> application is expecting to obtain from serial port and how does this
>> compare to wha
On Saturday 10 March 2007, Jiri Kosina wrote:
>On Sat, 10 Mar 2007, Gene Heskett wrote:
>> >I think there is alternative for you that can be done completely in
>> >userland, without seeding mess into the kernel driver - do you think
>> > it would be feasible that you create a trivial and small libr
On Saturday 10 March 2007, Jiri Kosina wrote:
>On Sat, 10 Mar 2007, Gene Heskett wrote:
>> >So these broken programs think that while talking to hiddev device,
>> > they are in fact receiving data from serial port, right?
>>
>> I believe that to be the case, this code is very old and moldy.
>
>That
Jiri Kosina wrote:
> I am still however pretty far from being convinced that this will make
> your application work. But as I absolutely don't know what your
> application is expecting to obtain from serial port and how does this
> compare to what it is getting from usb hiddev, it's just wild guess
On Sat, 10 Mar 2007, Gene Heskett wrote:
> >I think there is alternative for you that can be done completely in
> >userland, without seeding mess into the kernel driver - do you think it
> >would be feasible that you create a trivial and small library, that
> I'm not up to writing a library. 15
On Sat, 10 Mar 2007, Gene Heskett wrote:
> >So these broken programs think that while talking to hiddev device, they
> >are in fact receiving data from serial port, right?
> I believe that to be the case, this code is very old and moldy.
That's quite sad. In fact, it would quite surprise me if th
On Saturday 10 March 2007, Jiri Kosina wrote:
>On Thu, 8 Mar 2007, Gene Heskett wrote:
>> I believe the problem to be that when their version of upsd is trying
>> to open the /dev/name its given, it is assuming and hard coded to do
>> the ioctl's to set the ports speed in baudrate, width of word, p
On Saturday 10 March 2007, Jiri Kosina wrote:
>On Fri, 9 Mar 2007, Gene Heskett wrote:
>> Oh? I wasn't aware of that. What other data paths can it use besides
>> a usb port?
>
>Until 2.6.20, HID in kernel was USB-only thing. In 2.6.20 I have
> distilled the generic HID layer, which is now also ho
On Fri, 9 Mar 2007, Gene Heskett wrote:
> Oh? I wasn't aware of that. What other data paths can it use besides a
> usb port?
Until 2.6.20, HID in kernel was USB-only thing. In 2.6.20 I have distilled
the generic HID layer, which is now also hooked by the Bluetooth code, as
there are many Blu
On Thu, 8 Mar 2007, Gene Heskett wrote:
> I believe the problem to be that when their version of upsd is trying to
> open the /dev/name its given, it is assuming and hard coded to do the
> ioctl's to set the ports speed in baudrate, width of word, parity etc.
Hi Gene,
first, sorry for replying
On Friday 09 March 2007, Adam Kropelin wrote:
>Gene Heskett wrote:
>> On Thursday 08 March 2007, Gene Heskett wrote:
>>> Greetings;
>>>
>>> Belkin is being non-responsive to requests for updated drivers for
>>> their line of UPS's, all of which now have a USB port which is the
>>> Belkin recommende
On Fri, 09 Mar 2007 19:28:24 -0500, Gene Heskett <[EMAIL PROTECTED]> wrote:
> > should. Try to resend to <[EMAIL PROTECTED]> and cc: to linux-kernel. HID
> > is not specific to USB.
> I did just now send a message to jiri, but it bounced at approximately C
> speed, plus or minus a few percent.
>
On Friday 09 March 2007, Adam Kropelin wrote:
>Gene Heskett wrote:
>> On Thursday 08 March 2007, Gene Heskett wrote:
>>> Greetings;
>>>
>>> Belkin is being non-responsive to requests for updated drivers for
>>> their line of UPS's, all of which now have a USB port which is the
>>> Belkin recommende
On Friday 09 March 2007, Pete Zaitcev wrote:
>On Fri, 09 Mar 2007 01:03:32 -0500, Gene Heskett
<[EMAIL PROTECTED]> wrote:
>> Its been about a day now, and no one has commented. Am I an idiot or
>> ??
>
>I think it means that Jiri Kosina is not on this list. I haven't got
>a clue if what you propo
Gene Heskett wrote:
> On Thursday 08 March 2007, Gene Heskett wrote:
>> Greetings;
>>
>> Belkin is being non-responsive to requests for updated drivers for
>> their line of UPS's, all of which now have a USB port which is the
>> Belkin recommended way to talk to these things.
>>
>> Unforch, the bel
On Fri, 09 Mar 2007 01:03:32 -0500, Gene Heskett <[EMAIL PROTECTED]> wrote:
> Its been about a day now, and no one has commented. Am I an idiot or ??
I think it means that Jiri Kosina is not on this list. I haven't got
a clue if what you propose is a good idea... Although in theory I should.
Try
On Thursday 08 March 2007, Gene Heskett wrote:
>Greetings;
>
>Belkin is being non-responsive to requests for updated drivers for their
>line of UPS's, all of which now have a USB port which is the Belkin
>recommended way to talk to these things.
>
>Unforch, the belkin supplied *nix stuff was last c
Greetings;
Belkin is being non-responsive to requests for updated drivers for their
line of UPS's, all of which now have a USB port which is the Belkin
recommended way to talk to these things.
Unforch, the belkin supplied *nix stuff was last compiled on an rh5.2
machine using gcc-2.7.2, so the
Am Montag, 12. Februar 2007 19:22 schrieb Alan Stern:
> driver.c:usb_unbind_interface(), which calls usb_autoresume_device().
> That would force it to wait until usb_suspend_interface() finished.
I had overlooked that. Thanks.
> The other way is to call usb_driver_release_interface(). I assume
On Mon, 12 Feb 2007, Oliver Neukum wrote:
> Hi,
>
> concerning this code from usb_suspend_interface(), what keeps "driver"
> valid? I can see pm_lock protecting against usb_claim_interface(), but
> what about driver (un)registration?
>
> driver = to_usb_driver(intf->dev.driver);
>
>
Hi,
concerning this code from usb_suspend_interface(), what keeps "driver"
valid? I can see pm_lock protecting against usb_claim_interface(), but
what about driver (un)registration?
driver = to_usb_driver(intf->dev.driver);
if (driver->suspend && driver->resume) {
Hello.
elmar gerdes wrote:
> to make this short:
> Is anybody working on a UDC driver for the Alchemy Au1550
> (MIPS-based)?
> If you are interested in details, please read on:
> I'm working with an Au1550-based board and would like to run it as a USB
> device. There have been a few driver
Hi folks,
to make this short:
Is anybody working on a UDC driver for the Alchemy Au1550
(MIPS-based)?
If you are interested in details, please read on:
I'm working with an Au1550-based board and would like to run it as a USB
device. There have been a few drivers around for Au1xxx-ba
Alan Stern wrote:
> On Wed, 13 Dec 2006, Garrett D'Amore wrote:
>
>
>> I've done some more debugging. I've not had success in getting a debug
>> kernel built that will boot my system (Ubuntu) yet, and I don't know why
>> _that_ is a problem, but it takes ~4 hours per attempt (compiling Linux
>>
On Wed, 13 Dec 2006, Garrett D'Amore wrote:
> I've done some more debugging. I've not had success in getting a debug
> kernel built that will boot my system (Ubuntu) yet, and I don't know why
> _that_ is a problem, but it takes ~4 hours per attempt (compiling Linux
> is _slow_ on this Via 1GHz sy
I've done some more debugging. I've not had success in getting a debug
kernel built that will boot my system (Ubuntu) yet, and I don't know why
_that_ is a problem, but it takes ~4 hours per attempt (compiling Linux
is _slow_ on this Via 1GHz system), so I took a different tack.
I started using t
On Thu, 7 Dec 2006, Garrett D'Amore wrote:
> I'm developing a USB "transport protocol" (for a thin-client
> application, that basically allows a remote server to access the USB bus
> on a thin-client device, e.g. so you can access your USB thumbdrive
> using your thin-client.) We have this workin
I'm developing a USB "transport protocol" (for a thin-client
application, that basically allows a remote server to access the USB bus
on a thin-client device, e.g. so you can access your USB thumbdrive
using your thin-client.) We have this working already for other
platforms, so the protocol is "k
1 - 100 of 385 matches
Mail list logo
