On Thursday 19 April 2007 2:55 am, Li Yang wrote:
Update Kconfig, Makefile, gadget_chip.c, ether.c for newly added Freescale
Highspeed USB device driver.
Signed-off-by: Li Yang [EMAIL PROTECTED]
---
drivers/usb/gadget/Kconfig| 21 +
On Thursday 19 April 2007 10:48 am, David Brownell wrote:
But after Oliver's hack, there was still:
rndis_host 3-1:1.0: dev can't take 1558 byte packets (max 0)
And that means something else: the device took the RNDIS
initialization request, but didn't return a sane response.
So it's
On Wednesday 18 April 2007 8:42 am, Alan Stern wrote:
On Wed, 18 Apr 2007, Johannes Berg wrote:
The comparable routine in uhci-hcd includes this code:
if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags) || uhci-dead)
goto done;
and likewise, ehci_hub_status_data()
On Thursday 19 April 2007 7:53 pm, Li Yang-r58472 wrote:
Hi Dave,
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Friday, April 20, 2007 2:24 AM
To: Li Yang-r58472
Cc: [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net; Schmid
Bruce-R62923
On Thursday 19 April 2007 8:56 pm, Li Yang-r58472 wrote:
On Thursday 19 April 2007 2:53 am, Li Yang wrote:
+static void *fsl_alloc_buffer(struct usb_ep *_ep, unsigned bytes,
+ dma_addr_t *dma, gfp_t gfp_flags)
+{...
+}
You still need to fix this to
On Wednesday 18 April 2007 1:43 am, Johannes Berg wrote:
It seems to me that the timer shouldn't be scheduled when we go into
suspend,
Right ... this would be a post-2.6.21 fix right?
Do you know which specific line schedules that timer?
but I'll leave the proper fix up to somebody else.
Someone might want to look at this... presumably the bug
shows up in current code.
-- Forwarded Message --
Subject: [avrdude-dev] ser_posix.c: is select()ing for the write descriptor
useful at all?
Date: Wednesday 18 April 2007 1:36 pm
From: Joerg Wunsch [EMAIL PROTECTED]
To:
On Monday 05 February 2007 12:24 am, Li Yang wrote:
Add FSL_USB2_DR_OTG mode support to ehci-fsl driver.
Signed-off-by: Li Yang [EMAIL PROTECTED]
I guess I don't see any point to this patch. There's no support
for any dual-role functionality, is there? Nothing senses any
ID-pin in a
On Tuesday 17 April 2007 8:31 am, Oliver Neukum wrote:
Am Dienstag, 17. April 2007 17:18 schrieb Mark Glassberg:
usb 3-1: new full speed USB device using uhci_hcd and address 2
usb 3-1: ep0 maxpacket = 8
usb 3-1: skipped 4 descriptors after endpoint
usb 3-1: default language 0x0409
usb
ensuring that the references from the quirk tables
are gone, and that the function using those quirk tables is also gone.
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/usb/host/ohci-pci.c
===
--- g26.orig/drivers/usb
On Tuesday 17 April 2007 2:23 pm, Laurent Pinchart wrote:
Hi everybody,
I came across a device which exposes class specific interface descriptors
(CS_INTERFACE) that the current Linux kernel code can't parse.
Most USB devices describe the class specific interface data between the
On Tuesday 17 April 2007 2:56 pm, Laurent Pinchart wrote:
I had a look at a few Linux drivers, but had trouble finding complete
datasheets for the chips. It seems the FTDI232BM support 500kb/s, but I found
no protocol documentation describing available RTS modes.
The newer FTDI 232R series
Update usbnet so that ethtool reports the name of the minidriver in use
(e.g. asix, cdc_ether, dm9601, rndis_host) instead of usbnet. This is a
better match to how other network drivers work, resolving a minor open issue.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb
On Tuesday 17 April 2007 4:22 pm, Erik Hovland wrote:
The functions device_add and device_create_file return status and
that status is annotated as 'must check'.
This patch checks the return values and then unwinds work as necessary.
This should already be fixed by a patch in Greg's USB
On Tuesday 17 April 2007 4:34 pm, Erik Hovland wrote:
Because dev_kfree_skb_any will dereference the skb before actually
freeing we need to check to make sure skb is not null. This is because
at line 1655 we might have hit the goto because the skb could not be
allocated.
Erm, sortof. (And
for RNDIS_QUERY in one routine
- Use that wrapper when getting the Ethernet address
- Whitespace fixes
Plus add a comment noting the open issues about some RNDIS clients still
needing TBD kinds of browbeating to accept non-jumbogram packets.
Signed-off-by: David Brownell [EMAIL PROTECTED
Minor doc update to linux/usb/ch9.h ... say where USB_DT_CS_* came
from and update the definitions to match how they're derived there.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/include/linux/usb/ch9.h2007-02-28 12:46:02.0 -0800
+++ g26/include/linux/usb/ch9.h 2007
On Monday 16 April 2007 2:15 pm, Alan Stern wrote:
There's no question that it will become more important in the future, as
people start bringing more stringent requirements for their Isochronous
applications. It's an area in which Linux's USB support has traditionally
been rather weak,
On Monday 16 April 2007 12:57 pm, Alan Stern wrote:
This patch (as900) fixes some driver-core bogosity recently introduced
into the gendisk driver by Kay's block-device.patch.
Shame, shame... :-)
Doesn't apply to 2.6.21-rc7 ... ???
In which release I do sometimes see slab corruption
On Friday 13 April 2007 10:26 am, Laurent Pinchart wrote:
The driver needs to find the relationship between the host clock and the
device clock. The device clock/SOF counter synchronisation can be achieved
using the SCR values received with every data packet, but I found no easy way
to
On Friday 13 April 2007 2:11 pm, Matt Reimer wrote:
I'm getting a hang in s3c2410_udc.c's nuke() function which is due to
the same usb_request being queued back-to-back, with the result that
the request on the endpoint's queue points to itself, thus causing
nuke() to loop infinitely. (See
On Friday 06 April 2007 11:21 am, Alan Stern wrote:
On Fri, 6 Apr 2007, David Brownell wrote:
Again, power_state clearly being on the way out, we have alternate
solutions for what it previously seemed to solve.
Yes. However there is still one aspect for which we haven't fashioned
On Sunday 15 April 2007 11:07 am, John Wojnaroski wrote:
Hi,
I've been plowing through the various specs on USB trying to find an
answer, but my eyes are starting to hurt ;-)
Perhaps some one knows the answer and a pointer to the reference
Does USB require a CRC of the data packet for
On Thursday 12 April 2007 8:51 am, [EMAIL PROTECTED] wrote:
Hayes, Stuart wrote:
EHCI controllers that don't cache enough microframes can get MMF
errors when CPU frequency changes occur between the start and
completion of split interrupt transactions, due to delays in reading
main memory
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 contains
On Monday 09 April 2007 4:35 pm, Greg KH wrote:
On Mon, Apr 09, 2007 at 11:52:31AM -0400, Alan Stern wrote:
There is one significant difference between the behavior of root hubs
(as embodied in host controller hardware) and external hubs: When a
remote-wakeup signal is received, an external
On Monday 09 April 2007 7:50 am, Alan Stern wrote:
void usb_kick_khubd(struct usb_device *hdev)
{
+ /* FIXME: What if hdev isn't bound to the hub driver? */
We should just disallow that. There's no reason for us to risk
the integrity of USB framework by letting any other driver manage
On Monday 09 April 2007 7:46 am, Alan Stern wrote:
This patch (as892) removes the locktree routine from the hub driver.
It currently is used in only one place, by a single kernel thread;
hence it isn't doing any good.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
---
Sorry, Dave -- I
On Friday 06 April 2007 8:08 am, Alan Stern wrote:
On Thu, 5 Apr 2007, David Brownell wrote:
On Thursday 05 April 2007 1:04 pm, Alan Stern wrote:
This patch (as880) strives to keep the PM core's idea of a USB
interface's power state in synch with usbcore's own idea. In the end
that the controller has not been
tampered with.
The problem is fixed by turning off the Configured Flag whenever a
BIOS handoff is attempted, whether it succeeds or not.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Index: usb-2.6/drivers
, but it definitely is legal now. Merely
unbinding a USB driver will do it.
Furthermore, I've never seen any occurrences of this warning that
really did signal an actual bug or error condition. At this point it
has outlived its purpose.
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Signed-off-by: David
On Thursday 05 April 2007 1:04 pm, Alan Stern wrote:
This patch (as880) strives to keep the PM core's idea of a USB
interface's power state in synch with usbcore's own idea. In the end
this doesn't really matter, but it's better to be consistent.
ISTR trying this originally and watching it
-- Forwarded Message --
Subject: [PATCH] USB gadget rndis: fix struct rndis_packet_msg_type unaligned
bug
Date: Thursday 05 April 2007 9:02 pm
From: Wu, Bryan [EMAIL PROTECTED]
To: David Brownell [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
linux-kernel
-off-by: Milan Svoboda [EMAIL PROTECTED]
Other updates:
- Do that using platform_get_irq()
- Switch to platform_driver_probe()
- Handle device_add() errors
- Remove function sysfs attribute and its potential errors
- Whitespace cleanups
Signed-off-by: David Brownell [EMAIL PROTECTED
On Sunday 01 April 2007 8:16 pm, Greg KH wrote:
The way to properly solve this is to just never care about recycling
urbs. Look at what the visor driver does as an example of how you can
just create a new urb for _every_ instance, fire it off, and then forget
about it. It gets used and
That can certainly work, and it has the advantages of simplicity.
I wouldn't use that strategy in every driver of course, but I'd
guess it's fine for the serial and usblp cases mentioned here.
Why would you not want it in every driver?
For starters, your pre-emptive claim that
On Monday 02 April 2007 11:45 am, Felipe Balbi wrote:
[PATCH] Add -o option to redirect the output of testusb to a file.
Why not testusb ... file ??
-
Take Surveys. Earn Cash. Influence the Future of IT
Join
On Monday 02 April 2007 12:42 pm, Felipe Balbi wrote:
Hello all,
A simple question:
Where can I find details about each test testusb is running? I need to
understand each of them to understand its outputs...
The source code.
That raises the question how the issue is to be solved. To me the obvious
solution to a lack of memory ordering is to specify memory ordering
explicitely. However, I seem to be in the minority.
The other way around it would be to use wait_for_completion().
Oppinions?
Memory barriers are
On Friday 30 March 2007 7:59 pm, Alan Stern wrote:
Nope. If an smp_mb() is needed, the reason is because of other
driver-internal bugs.
Remember that the driver isn't allowed to so much as *LOOK* at any
field of an URB until the completion callback. That generalizes:
it
On Friday 30 March 2007 11:10 am, Felipe Balbi wrote:
Hello all,
I'm trying to run testusb on a tusb6010 device to test it's host mode
functionalities. I compiled the latest linux-omap gittree and enabled
the OTG mode.
I'm setting it to host mode by echoing host to
On Thursday 29 March 2007 3:06 pm, Randy Dunlap wrote:
On Tue, 20 Feb 2007 01:06:54 +0100 Adrian Bunk wrote:
On Sun, Jan 14, 2007 at 06:36:10AM -0800, David Brownell wrote:
On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
-- snip --
Waiting for Tony to submit bugfixes
out when
no such address is available (highmem) which should help usbmon.
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/core/message.c 2007-03-12 00:59:52.0 -0700
+++ g26/drivers/usb/core/message.c 2007-03-31 18
On Thursday 29 March 2007 11:58 pm, Oliver Neukum wrote:
/* complete() can reenter this HCD */
spin_unlock (ehci-lock);
usb_hcd_giveback_urb (ehci_to_hcd(ehci), urb);
spin_lock (ehci-lock);
The comment gives you the reason and is right. The locks must be dropped.
On Thursday 29 March 2007 1:09 pm, Alan Stern wrote:
On Wed, 28 Mar 2007, David Brownell wrote:
Here's the exact text from the spec:
If the endpoint instead responds to the OUT/DATA transaction with
a NYET handshake, this means that the endpoint accepted the data
but does
On Friday 30 March 2007 11:33 am, Oliver Neukum wrote:
Am Freitag, 30. März 2007 19:56 schrieb Greg KH:
The bottom line is, there's no excuse for using any kind of smp_mb()
in USB drivers. None at all. When we have 100Gbit/s USB, then perhaps
we can talk about it.
Perhaps then, but
On Friday 30 March 2007 1:38 pm, Oliver Neukum wrote:
Am Freitag, 30. März 2007 22:04 schrieb David Brownell:
Remember that if every completion callback does
status = urb-status;
at the top, the urb-status issue will by definition go away. That's
Only if it does smp_mb
On Friday 30 March 2007 2:49 pm, Oliver Neukum wrote:
Nope. If an smp_mb() is needed, the reason is because of other
driver-internal bugs.
Remember that the driver isn't allowed to so much as *LOOK* at any
field of an URB until the completion callback. That generalizes:
it mustn't do
On Wednesday 28 March 2007 12:07 am, Pandita, Vikram wrote:
Scenario:
MUSBHDRC is acting as Host. Netchip2280 is acting as device.
On MUSBHDRC run the usbtest 14 and see the error -32.
OK, that CATC snapshot was informative.
- SETUP, write 8 bytes, fine
- SETUP, read them back, fine,
On Wednesday 28 March 2007 2:29 am, Pandita, Vikram wrote:
(**) 8.5.1 in the USB 2.0 spec says that after a NYET handshake,
the host controller must return to using a PING token until the
endpoint indicates it has space.
Clearly, the HDRC did not issue any PINGs ... it just went right
On Wednesday 28 March 2007 9:09 am, Alan Stern wrote:
On Wed, 28 Mar 2007, Tony Lindgren wrote:
Hi,
Here's a little patch to make sure tranfer_buffer is always if DMA
is temporarily unavailable. I ran into this with tusb6010 that
currently can only do limited DMA. This fixes a
On Wednesday 28 March 2007 8:25 am, Alan Stern wrote:
On Tue, 27 Mar 2007, David Brownell wrote:
Hmm... A CPU has to access all that data, and reading a cache line
at a time surely as better. Although on the other hand, it's something
streaming and thus just using the cache space
On Wednesday 28 March 2007 9:04 am, Alan Stern wrote:
On Wed, 28 Mar 2007, David Brownell wrote:
On Wednesday 28 March 2007 2:29 am, Pandita, Vikram wrote:
(**) 8.5.1 in the USB 2.0 spec says that after a NYET handshake,
the host controller must return to using a PING token until
On Wednesday 28 March 2007 11:28 am, Pete Zaitcev wrote:
On Wed, 28 Mar 2007 11:25:54 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
That is, when the application manages DMA adressing? The driver should
provide both the DMA and regular address, since not every underlying
(**) 8.5.1 in the USB 2.0 spec says that after a NYET handshake,
the host controller must return to using a PING token until the
endpoint indicates it has space.
Clearly, the HDRC did not issue any PINGs ... it just went right
to the status handshake. Fishy,
On Wednesday 28 March 2007 4:08 pm, David Brownell wrote:
You're using a different definition of complete than I am. I'm using
the same definition that a normal bulk OUT would use: ready to accept
one more OUT packet.
That is: NYET/PING is a handshake used to mark completion
On Tuesday 27 March 2007 10:43 am, Pete Zaitcev wrote:
On Tue, 27 Mar 2007 14:30:52 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
--- a/drivers/usb/serial/option.c 2007-03-27 13:31:04.0 +0200
Why don't you just use kmalloc here? The needless use of usb_buffer_alloc
always
On Tuesday 27 March 2007 3:48 pm, Pete Zaitcev wrote:
On Tue, 27 Mar 2007 13:40:23 -0700, David Brownell [EMAIL PROTECTED] wrote:
Actually, HID was one of the original motivations for using that.
Dave Miller noticed the cost for a USB keyboard was excessive on
(ISTR) SPARC64, and avoiding
On Monday 26 March 2007 9:19 am, Alan Stern wrote:
On Mon, 26 Mar 2007, Pandita, Vikram wrote:
If the MUSBHDRC really did send an extra OUT token, then the bug is in the
MUSBHDRC. If it really sent an IN token but the Netchip set the flag for
an OUT token, then the bug is in the Netchip.
On Monday 26 March 2007 10:36 am, David Brownell wrote:
On Monday 26 March 2007 9:19 am, Alan Stern wrote:
On Mon, 26 Mar 2007, Pandita, Vikram wrote:
If the MUSBHDRC really did send an extra OUT token, then the bug is in the
MUSBHDRC. If it really sent an IN token but the Netchip set
On Monday 26 March 2007 2:11 am, Girish wrote:
pxa27x-ohci: created debug files
pxa27x-ohci pxa27x-ohci: resetting from state 'reset', control = 0x0
pxa27x-ohci pxa27x-ohci: OHCI controller state
pxa27x-ohci pxa27x-ohci: OHCI 1.0, NO legacy support registers
pxa27x-ohci pxa27x-ohci: control
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
,
causing a retry. If the peripheral doesn't resend that data correctly,
that causes a test failure. (And my test rig doesn't resend correctly...)
This is based on a patch from ZHENG LEI [EMAIL PROTECTED]
against 2.6.10 code, resolving some of the ep0out problems.
Signed-off-by: David Brownell [EMAIL
Fix annoying build warning when CONFIG_USB_SERIAL_GENERIC is undefined.
drivers/usb/serial/generic.c:24: warning: `generic_probe' declared `static'
but never defined
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/usb/serial/generic.c
On Friday 23 March 2007 9:11 am, Alan Stern wrote:
We don't clear the halt because the host is never supposed to clear halts
on ep0. If the halt is a protocol stall (the normal case) then the
device will clear it automatically when it receives the next SETUP packet.
If the halt is a
packages: L is SSOP, Q is QFN.)
Signed-off-by: David Brownell [EMAIL PROTECTED]
Index: g26/drivers/usb/serial/ftdi_sio.c
===
--- g26.orig/drivers/usb/serial/ftdi_sio.c 2007-03-12 00:59:53.0
-0700
+++ g26/drivers/usb
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 devices
On Friday 23 March 2007 8:21 pm, Alan Stern wrote:
... 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 ...
Whoops! You're right. Sometimes those little details fade
On Thursday 22 March 2007 12:54 pm, Tino Keitel wrote:
On Thu, Mar 22, 2007 at 15:40:40 -0400, Alan Stern wrote:
_Something_ is generating those overcurrent
warnings, and it sure looks like a hardware malfunction.
But it works with 2.6.20.
So can you bisect to find what caused the
for the function reporting whether the board has
vbus sensing wired up.
GET_STATUS requests for endpoint status still acts strangely though, at least
given one flakey host doesn't always ack the first DATA packet, then the packet
that gets retransmitted doesn't have data!
Signed-off-by: David Brownell
On Wednesday 21 March 2007 1:28 pm, Greg KH wrote:
I'll wait to add this to the tree when there is some code using it.
So for example if both Ragner's gadget code, and the Berlios host
code, agreed to use that...? Even though neither one is yet in
shape to merge upstream, I'd think it would
On Tuesday 20 March 2007 8:29 am, Ragner N Magalhães wrote:
Em Seg, 2007-03-19 às 15:09 -0700, ext David Brownell escreveu:
I see a lot of *_UNDEFINED symbols, which seem dubious. If it's
not defined, then it shouldn't be defined! Wouldn't want to see
anyone assume that if a value
On Tuesday 20 March 2007 7:49 am, Alan Stern wrote:
I am sorry. HAL? Where do I get this daemon?
It's part of the hal package, which is included in Fedora and presumably
other distributions as well. See
http://www.freedesktop.org/Software/hal
What would an embedded distro use
http://www.freedesktop.org/Software/hal
What would an embedded distro use though? HAL takes up
multi-megabytes.
A swapless system, with say 32 MB total RAM, probably won't find that
to be a usable solution ...
Gee Dave,
How did you know? That is exactly what we have, an
On Monday 19 March 2007 1:29 pm, Ragner Magalhaes wrote:
The following patch implements USB Video Class 1.1 as defined at
USB Device Class Definition for Video Devices, available at:
No it doesn't ... it declares on-the-wire *structures* passed.
There's not one line of implementation code there
On Monday 19 March 2007 8:10 am, Felipe Balbi wrote:
This patch adds some endpoints into omap_udc fifo_mode
for the three already modified gadget to work together
However, it's legit for code to hard-wire knowledge that
a given fifo_mode, a given endpoint exists ... so what you
On Saturday 17 March 2007 3:32 pm, Jon Smirl wrote:
Two devices I have that also have NO_REMOTE_WAKEUP are both Wifi
adapters. Wifi has it's own power saving scheme that allows it to poll
for activity without being fully powered.
Right, but that still consumes power. And WiFi isn't
On Sunday 18 March 2007 8:16 pm, Li Yang-r58472 wrote:
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 17, 2007 6:38 AM
To: linux-usb-devel@lists.sourceforge.net
Cc: Li Yang-r58472; [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] [PATCH
On Wednesday 14 March 2007 6:33 am, Wael Adel wrote:
hi all,
Actually, the steps mentioned in USB Linux testing in the following link:
http://www.linux-usb.org/usbtest/index.html#gadgets
these steps for testing r not vey clear to me, so i will tell u what i
have made:
1. i have
On Thursday 15 March 2007 6:46 pm, Jan 'RedBully' Seiffert wrote:
Hi,
product i'm talking about:
http://www.devolo.com/co_EN/produkte/dlan/mldlanduo.html
Networking over power lines. :)
Introduction:
Due to some cabeling constrains, i decided connecting some clients over
powerline
On Wednesday 14 March 2007 5:18 am, Li Yang wrote:
Apparently this gadget doesn't support setting usb_cdc_line_coding.
It does support it ... but that support is buggy. It should be issuing
a read request before doing the memcpy(); instead, it wrongly assumes
that something else already issued
On Tuesday 13 March 2007 6:39 am, Mark Lord wrote:
Oliver Neukum wrote:
If we get to destroy_serial(), how can ports still be open?
(1) open up a ckermit session on /dev/usb_serial_port_0.
(2) suspend the machine (to RAM).
(3) the suspend logic removes all USB devices.
Actually on most
On Thursday 15 March 2007 11:01 am, Wael Adel wrote:
On Wednesday 23 August 2006 21:35 am, David Brownell wrote:
Both the UDC driver and gadgetfs are built as loadable modules. After
successfully loading these two modules, I was able to mount gadget fs by
doing mount -t gadgetfs gadgetfs
On Thursday 08 March 2007 7:33 am, Alan Stern wrote:
On Wed, 7 Mar 2007, Sarah Bailey wrote:
What transfer flags should usbfs2 expect userspace to set?
I have opinions on most of the transfer flas, but I'm unsure about
URB_NO_FSBR. ...
In any case, URB_NO_FSBR is merely a minor
On Wednesday 07 March 2007 1:10 pm, [EMAIL PROTECTED] wrote:
OK, I've made an attempt to solve this issue without using such a large
hammer. Instead of shutting off the entire periodic schedule during
cpufreq changes, this patch will just inactivate (using the I bit in
qh-hw_info1,
On Tuesday 06 March 2007 11:12 pm, Ajay Jain wrote:
Hello,
We had the following questions for a peripheral controller driver. We
do have an idea about some of the answers, evidently our understanding
is not complete.
1. The gadget can ask the peripheral controller to send/receive zero
On Wednesday 07 March 2007 8:45 am, Pandita, Vikram wrote:
Alan
If the peripheral driver is to decide to send a ZLP or not based on the
length of data transfer, then the API given to Gadget driver of req.zero
is redundant.
My understanding is that the Gadget driver should respect the API
On Monday 05 March 2007 3:26 am, Michael Buesch wrote:
Actually, it seems like I will run into other kinds of nasty problems
due to stupid design of the HCD code. The OHCI code #includes
the various drivers, which have a module_init each. So if you
compile PCI and SSB support, you have
On Thursday 01 March 2007 10:49 pm, Greg KH wrote:
On Thu, Mar 01, 2007 at 05:45:08PM -0800, David Brownell wrote:
On Thursday 01 March 2007 4:20 pm, Max Dmitrichenko wrote:
Hi!
I get following warnings on spar64:
Kernel unaligned access at TPC[1000c9e4] ehci_hub_control+0x54c
On Friday 02 March 2007 7:38 am, Alan Stern wrote:
On Fri, 2 Mar 2007, Max Dmitrichenko wrote:
Strange ... but, ACK.
It would be a good idea to track this down a little further. The
comment
in the code _should_ be correct. If it isn't, then something funny is
going
On Thursday 01 March 2007 6:32 am, Milan Svoboda wrote:
This patch adds second parameter to gpio_direction_output function.
This allows users to specify default output level.
Patch covers pxa and ixp4xx plus driver for pxa2xx_udc.
Patch is agains 2.6.21-rc1
What do you think about this
On Wednesday 28 February 2007 7:46 am, Milan Svoboda wrote:
This patch lets the pxa2xx_udc to use the generic gpio layer.
Looks pretty good. However, let's try to get the issue with
that second parameter to gpio_direction_output() sorted first,
so that this driver only needs one patch.
I'll
On Sunday 25 February 2007 9:29 pm, Greg KH wrote:
That's what Documentation/ABI/ is there for :)
Someone snuck that in while I wasn't looking, it seems ... ;)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join
On Thursday 01 March 2007 4:20 pm, Max Dmitrichenko wrote:
Hi!
I get following warnings on spar64:
Kernel unaligned access at TPC[1000c9e4] ehci_hub_control+0x54c/0x68c
[ehci_hcd]
Despite of the comment in the patched code, the type cast used there
does make unaligned access. The fix
On Wednesday 28 February 2007 6:36 am, Milan Svoboda wrote:
On Monday 26 February 2007 5:35 am, Milan Svoboda wrote:
There is one problem, thought. Original code used:
static inline void udc_gpio_init_pullup(unsigned gpio)
{
pxa_gpio_mode((gpio GPIO_MD_MASK_NR) |
On Tuesday 27 February 2007 7:58 pm, Jon Smirl wrote:
Linux seems to be missing a header file for the hub class. For example
if you look at the source for lsusb.c it is using a lot of hex
constants since there aren't symbols defined.
As Alan observed, there *is* such a file, just not one for
On Tuesday 27 February 2007 3:16 pm, Andrea Arcangeli wrote:
On Tue, Feb 27, 2007 at 01:56:59PM -0800, David Brownell wrote:
You could try updating /etc/modprobe.conf with options ov511 cams=2
cams=2 fixed it! So I've a real clean workaround now.
And before doing any work on ov511
On Monday 26 February 2007 12:54 am, Sarah Bailey wrote:
On Sun, Feb 25, 2007 at 08:53:03AM -0800, David Brownell wrote:
On Sunday 25 February 2007 12:57 am, Sarah Bailey wrote:
I haven't seen any evidence that the kernel-side aio is substantially
more efficient than the GNU libc
On Wednesday 28 February 2007 10:09 am, Andreas Vilinski wrote:
Hi
I try to implement a mass storage gadget driver in user space. The
restriction - it must be single threaded.
The usb.c example, that uses the gadgetfs module has two trehads running.
But it's currently possible to poll
On Monday 26 February 2007 9:51 am, Andrea Arcangeli wrote:
On Mon, Feb 26, 2007 at 09:36:55AM -0800, David Brownell wrote:
That's not a heuristic ... as I assume you know. No guesswork
You assume wrong, I know nothing about that code, ...
I was referring to the definition of a heuristic
301 - 400 of 5112 matches
Mail list logo
