Hello all, new linux convert here. My company is creating gaming
devices and so we are programming a Reel Control Unit. This device
requires a 64 BYTE message with every message
I am using a 2.4.26 kernel (knoppix scaled down). My problem is that
once we plug in the device and begin talking t
Hi. This is the qmail-send program at maxis11.pacific.net.sg.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
<[EMAIL PROTECTED]> 203.120.90.230 failed after I sent the message.
Re
Hi,
We are writing a USB Bluetooth driver with SCO
support using a sample hardware that we have. We have
run into some questions regarding the implmentation of
ISOC/SCO support for the card. While enumerating we
are getting as many endpoints on interface 1 as
mentioned in the Bluetooth spec. We
On Fri, 24 Sep 2004 16:58:42 -0700 (PDT)
Raymond W <[EMAIL PROTECTED]> wrote:
> Once I port it to 2.6 I will read up on the how-to of submitting, but I was
> unsure if 'the community' still had interest in 2.4 kernel drivers.
It depends. Generally, there is a sense that new stuff should go to 2.6
Hello
I've written a device driver for a 3rd party's product so that I might use it on my
machine.
However I am still using the 2.4, so naturally that is the kernel the driver works
with.
Should/could I submit it here, or would I be better off distributing it on my own?
Once I port it to 2.6 I
Hi!
> > > The transitions to and from the device-idle states needed for
> > > suspend-to-disk aren't well defined.
> >
> > I'll answer questions if you promise to submit documentation patch
> > ;-)). device-idle states needs to ensure:
>
> If I know what to write I'll write it.
Grea
> I mean, how should the implementation work? There's actually two
> problems. (1) How should we preserve the existence of devices across a
> per-device power-off suspend (i.e., not system-wide)? (2) How should we
> reinitialize devices during the resume-from-idle that occurs after a
> memo
Am Freitag, 24. September 2004 22:15 schrieb Alan Stern:
> Here's an example. Suppose the device is in D2 when suspend-to-disk
> starts. Assume it's a PCI device, so the driver doesn't need to do
> anything more to idle it, and thus the last state the driver remembers is
> that the device was in
Am Freitag, 24. September 2004 22:15 schrieb Alan Stern:
> On Fri, 24 Sep 2004, Oliver Neukum wrote:
>
> > > All right, the whole point is moot. But it does raise an interesting
> > > question. The USB subsystem has no way to preserve the existence of
> > > devices across power-off. If people w
Am Freitag, 24. September 2004 21:13 schrieb Alan Stern:
> All right, the whole point is moot. But it does raise an interesting
> question. The USB subsystem has no way to preserve the existence of
> devices across power-off. If people want to keep their mounted
> filesystems on a USB disk durin
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> > All right, the whole point is moot. But it does raise an interesting
> > question. The USB subsystem has no way to preserve the existence of
> > devices across power-off. If people want to keep their mounted
> > filesystems on a USB disk during susp
> Well, what I was _thinking_ of achieving (in a rather inadequate
> faint-hearted way) was to find a way of preventing disaster when there was
> a mounted filesystem on media that got removed or exchanged during the
> suspend. But there really is no way to prevent disaster when that
> happen
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> > Drivers will need to deal with this possibility. It also would be good if
> > they could place a suspended device into an "idle" state without having to
> > resume it first. I still think it's worthwhile trying to avoid resuming
> > the entire sys
On Friday 24 September 2004 18:48, Paulo Marques wrote:
> Duncan Sands wrote:
> > Hi Alan,
> >
> >
> >>Just a couple of minor comments:
> >>
> >>It's not really necessary to restrict yourself to printable Latin
> >>characters (although it is safer). After all, properly-formed string
> >>descript
> Drivers will need to deal with this possibility. It also would be good if
> they could place a suspended device into an "idle" state without having to
> resume it first. I still think it's worthwhile trying to avoid resuming
> the entire system just to write the memory image to a single sw
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> > > Firmware for swap devices must be in kernel always.
> >
> > Why is that? When idling devices before preparing the image there's no
> > need to power down so far that the device loses its firmware. When
> > reading the image back from the swap pa
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> > > Presumably the state would be the state at power up.
> >
> > What if, as you suggest, there are other hosts on the bus using the
> > device? Aren't they liable to alter the device from its power-up state?
>
> The same problem is facing probe(). T
> > Firmware for swap devices must be in kernel always.
>
> Why is that? When idling devices before preparing the image there's no
> need to power down so far that the device loses its firmware. When
> reading the image back from the swap partition you've got a fully-running
> kernel availab
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> Upon second thought, user space should write the firmware _before_
> it initiates suspend, so that the firmware is part of the image as it is
> read back. If you request a suspend without writing firmware, it's
> your fault. You brake it, you can keep th
> > > However when the restored image begins executing, drivers may expect the
> > > devices to be in the same state as before the image was created. This
> > > argues that idle devices must be in a known state, which is presumably one
> > > of minimum power usage. That would be okay, except:
>
Duncan Sands wrote:
Hi Alan,
Just a couple of minor comments:
It's not really necessary to restrict yourself to printable Latin
characters (although it is safer). After all, properly-formed string
descriptors may contain arbitrary UCS-16 characters. You could just
terminate the scanning when you
My box has:
:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05)
(prog-if 10 [OHCI])
Subsystem: ServerWorks OSB4/CSB5 OHCI USB Controller
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at f5e7 (32-bit, non-prefetchable)
:00:
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> > In PCI every state above 0 is "idle" -- but there's no reason that should
> > be true for every device in the system.
>
> So remote wakeup needs to be disabled, doesn't it?
PCI remote wakeup is a peculiar thing. It's not a regular interrupt; it's
a
> My feeling is that the kernel should _not_ save the firmware during a D3
> suspend. When the resume takes place the device should be unregistered
> and subsequently reprobed. Then the firmware can be loaded again by the
> same mechanism that loaded it in the first place.
Upon second thought,
> > The problem is ipw2100 requires an external on-disk firmware support. When
> > the device is put to D3 state, firmware needs to be unloaded. And the
> > firmware should be loaded again after the device is put to D0 state. But
> > currently there is no suspend/resume order(dependency) for the o
Hi Alan,
> Just a couple of minor comments:
>
> It's not really necessary to restrict yourself to printable Latin
> characters (although it is safer). After all, properly-formed string
> descriptors may contain arbitrary UCS-16 characters. You could just
> terminate the scanning when you find \
On Fri, Sep 24, 2004 at 02:27:27AM +, [EMAIL PROTECTED] wrote:
> Hello,
>
>Currently, the pl2303 driver doesn't support the TIOCINQ (or FIONREAD, same
> thing) ioctl. Following is a patch to resolve that problem. Issuing an IOCTL
> to the driver with one of the 2 proper requests will now
Am Freitag, 24. September 2004 16:48 schrieb Alan Stern:
> On Thu, 23 Sep 2004, Oliver Neukum wrote:
>
> > Ok. The meat of swsusp is in kernel/power::swsusp.c.
> > The call trace of the core is: (comments are mine)
> > free_some_memory(); // this would require anything that is in the page out path
On Fri, 24 Sep 2004, Oliver Neukum wrote:
> Hi,
>
> this seems to have large relevance for the power management stuff we've
> been discussing.
>
> Regards
> Oliver
>
> -- Weitergeleitete Nachricht --
>
> Subject: suspend/resume support for driver requires
On Fri, 24 Sep 2004, Duncan Sands wrote:
> The Freebox is a USB modem popular in France. It returns bogus string
> descriptors: while the string part is there, the length and type bytes
> are both zero. This patch detects that case and tries to recover a
> sensible string by scanning for printab
On Thu, 23 Sep 2004, Oliver Neukum wrote:
> Ok. The meat of swsusp is in kernel/power::swsusp.c.
> The call trace of the core is: (comments are mine)
> free_some_memory(); // this would require anything that is in the page out path to
> be active
> device_suspend(3) // this causes device state to
On Fri, 24 Sep 2004, Xu Levis-Q16136 wrote:
> Alan, thans for your great help!
>
> Why would i get many compile and link errors after i convert the new USB
> stack over to the old Config.in scheme? Does you mean the new USB stack
> source codes is not compatible with the old linux kernel(2.4.20)?
Ingo Molnar wrote:
>
> * Rui Nuno Capela wrote:
>
>> Then, in a silent suggestion from David Brownell, I hacked ohci_hcd.c,
>> forcing the OHCI_QUIRK_INITRESET flag behaviour, build a new kernel and
>> modules and voila', all USB is back to functionality.
>
>
> it would be cleaner to make this depe
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> Then, in a silent suggestion from David Brownell, I hacked ohci_hcd.c,
> forcing the OHCI_QUIRK_INITRESET flag behaviour, build a new kernel and
> modules and voila', all USB is back to functionality.
> diff -duPNr linux.0/drivers/usb/host/ohci-hcd.
Hi,
My laptop is a Compaq Presario 2516EA, loaded with Mandrake 10.0 Official,
which has been working fine until 2.6.9-rc2. Incidentally with -mm1 and
-mm2 the USB subsystem start failing miserably, due to errors while
(re)starting the ohci_hcd stuff.
By lurking on some recent threads on lkml, an
> o The callback gets called even before any ISOC
> transfer starts and we get urb->actual_length = 0 in
> every iteration of the read_isoc_callback. Also
> urb->iso_frame_desc[i].actual_length = 0 for all
> frames.
> What might be wrong ?
What is the status?
Duncan.
--
Hi,
this seems to have large relevance for the power management stuff we've
been discussing.
Regards
Oliver
-- Weitergeleitete Nachricht --
Subject: suspend/resume support for driver requires an external firmware
Date: Freitag, 24. September 2004 08:16
The Freebox is a USB modem popular in France. It returns bogus string
descriptors: while the string part is there, the length and type bytes
are both zero. This patch detects that case and tries to recover a
sensible string by scanning for printable Latin characters. This not
only causes the mod
On Thu, 23 Sep 2004 23:01:44 +0200, Marcel Holtmann wrote:
> Hi Jan,
>
> > I want to make a control program for an EIZO FlexScan T965 CRT monitor. The
> > monitor keys are reported to hiddev. Setting brightness, contrast etc is done
> > with control messages. I have attached a libusb program that
39 matches
Mail list logo
