Hi,
this is Joris' fixes reshuffelled as David requested.
- acm_set_control is not mandatory, honour that
- throtteling is reset upon open
- throtteling is read consistently when processing input data
Regards
Oliver
Signed-off-by: Joris van Rantwijk <[EMAIL PROTECTED]>
S
Oleg Verych wrote:
> Your intro pseudo-code:
>
> | g() {
> | char c;
> | struct S s; /* packed or not */
> | (s.intfield)++;
> | f(&s);
> | }
>
> Due to `c', `s' gets to be unaligned, i.e. light turned before you've
> touched a switch: layout of `c' is independed, it's a byt
Hi All,
Bulk source and the bulk sink tests that is integrated in the
test driver writes the data directly to the device without following
the cbw and csw protocol.That induces an endpoint error at our
hostcontroller layer.I think this may be the reason if i am not
wrong.Please guide me in thi
Am Donnerstag, 8. Februar 2007 02:25 schrieb Greg KH:
> Ok, again, I don't see this as being an issue from any other device that
> is on the bus, asking for power, yet not having any driver bound to it.
Other devices are not broken with respect to power.
The purpose of the driver is to charge bla
Am Donnerstag, 8. Februar 2007 02:25 schrieb Greg KH:
> Or is this in relation to the autosuspend issues?
These exist, too. You've added the blackberry to the quirk list.
This is incorrect. For once, somebody might compile a kernel
without your driver. In this case disabling power management
is w
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 7. Februar 2007 18:31 schrieb Pete Zaitcev:
>> On Wed, 7 Feb 2007 14:39:28 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> > Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
>>
>> > > static inline unsigned usb_get_uint16(__u
While sending the string descriptor, Gadget Zero does not send a ZLP in
case the packet size is maxpacket size, resulting in a USBCV failure.
The Ethernet Gadget has the following code which is missing from Gadget
Zero. Should this be added to the Gadget Zero also?
I have tested this change on
> Unfortunately I can't have the correct type for this field in C (it
> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
> can't get type-safety here anyway. Declaring this field __le16 is IMHO a
> poor attempt as it creates an illusion of type safety when in fact there
> is no
On Wed, 7 Feb 2007 16:35:41 -0800, "Greg KH" <[EMAIL PROTECTED]> said:
> From: Alan Stern <[EMAIL PROTECTED]>
>
> This patch (as841) removes from usbcore a couple of support routines
> meant to help with bandwidth allocation. With the changes to uhci-hcd
> in the previous patch, these routines a
I'm writing firmware for a number of USB devices, and it seems that most
of the time, I simply want a ordered/reliable communications stream
between host and device: I can build my actual protocol on top of this
in userspace. I've previously used usb-serial, but the performance
wasn't satisfact
Am Donnerstag, 8. Februar 2007 14:40 schrieb Edwin Olson:
> Attached is a fairly simple new driver ("susi" for "simple usb stream
> interface") that provides an ordered/reliable stream interface,
> compatible with usb-serial, except that it dispenses with the tty layer
> and it doesn't care abo
> I'll look at it in a few minutes, but first, what do you want to do that
> libusb can't do?
>
Perhaps I'm out of date, but the documentation for libusb seems to
indicate that the API is synchronous, which would limit the number of
outstanding URBs per endpoint to one (unless I made a pthrea
I forgot to ask an additional question:
Is it sensible to have multiple outstanding read URBs, in the way that
there are multiple outstanding write URBs?
On my embedded platform, it is fairly expensive to do write-merging in
order to send maximum length packets. (In other words, on my device, m
Am Donnerstag, 8. Februar 2007 14:40 schrieb Edwin Olson:
> * Is my locking correct?
Short answer: No.
Long answer:
/* prevent the device from being autosuspended */
retval = usb_autopm_get_interface(interface);
if (retval)
goto exit;
/* increment
Hi,
as the skeleton driver was made ready for autosuspend a race condition
was introduced. The reference to get device must be gotten before the
autosuspend counter is upped, as this operation may sleep, dropping BKL.
Dropping BKL means that the pointer to the device may become invalid.
Here's the
On Wed, 7 Feb 2007, Pete Zaitcev wrote:
> Alan, do you happen to know how much usb_iso_packet_descriptor thingies
> we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
> If we routinely get lots of them per URB then I need to rethink the line
> format and all other things. I
On Thu, 8 Feb 2007, Oliver Neukum wrote:
> Hi,
>
> as the skeleton driver was made ready for autosuspend a race condition
> was introduced. The reference to get device must be gotten before the
> autosuspend counter is upped, as this operation may sleep, dropping BKL.
> Dropping BKL means that th
On Wed, 7 Feb 2007, Alan Stern wrote:
> This patch (as850) disables remote wakeup on EHCI ports when the
> shutdown() method is called. If it is left active then some systems
> will reboot instead of powering off. This solves Bugzilla #7828.
I'm having second thoughts about this patch.
First o
Oliver Neukum <[EMAIL PROTECTED]> writes:
>> Unfortunately I can't have the correct type for this field in C (it
>> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
>> can't get type-safety here anyway. Declaring this field __le16 is IMHO a
>> poor attempt as it creates an illusi
On Wed, 7 Feb 2007, Oliver Neukum wrote:
> > Since we suspend entire devices, and not single interfaces, any value
> > coming from userspace will have to refer to the entire device. So are you
>
> No, user space can set values for each interface.
>
> User space can know which value would be the
Am Donnerstag, 8. Februar 2007 16:41 schrieb Sergei Organov:
> > If you do that, le16 is just as valid, especially if declared
> > unaligned.
>
> I don't think so:
>
> 1. 'unsigned char', be it used in the form of 'u8' or not, has neither
> alignment nor endianness problems, while le16 has bot
On Thu, 8 Feb 2007, Oliver Neukum wrote:
> Am Donnerstag, 8. Februar 2007 02:25 schrieb Greg KH:
>
> > Or is this in relation to the autosuspend issues?
>
> These exist, too. You've added the blackberry to the quirk list.
> This is incorrect. For once, somebody might compile a kernel
> without y
Alan Stern wrote:
> On Wed, 7 Feb 2007, Pete Zaitcev wrote:
> > Alan, do you happen to know how much usb_iso_packet_descriptor thingies
> > we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
> > If we routinely get lots of them per URB then I need to rethink the line
> > for
On Thu, 8 Feb 2007, Sergei Organov wrote:
> Unfortunately I can't have the correct type for this field in C (it
> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
> can't get type-safety here anyway. Declaring this field __le16 is IMHO a
> poor attempt as it creates an illusion
On Thu, 8 Feb 2007, Pandita, Vikram wrote:
> While sending the string descriptor, Gadget Zero does not send a ZLP in
> case the packet size is maxpacket size, resulting in a USBCV failure.
Not correct. Gadget Zero _does_ send a ZLP if the packet size is equal to
the maxpacket size, provided the
Am Donnerstag, 8. Februar 2007 17:00 schrieb Alan Stern:
> First of all, note that 3) above isn't a problem. If a driver doesn't
> have supports_autosuspend set, or if it calls usb_autopm_get_interface(),
> then the device won't be autosuspended at all. So we can eliminate this
> case; it's a
On Thu, 8 Feb 2007, Tilman Schmidt wrote:
> This breaks compilation of drivers/isdn/gigaset/bas-gigaset.c.
> If you pass on this patch, please pass on Andrew's
>
> fix-gregkh-usb-usbcore-remove-unused-bandwith-related-code.patch
>
> along with it.
Or else my as845 patch,
http://marc.theaimsgro
On Thu, 8 Feb 2007, Edwin Olson wrote:
> I forgot to ask an additional question:
>
> Is it sensible to have multiple outstanding read URBs, in the way that
> there are multiple outstanding write URBs?
Yes.
> On my embedded platform, it is fairly expensive to do write-merging in
> order to sen
On Thu, 8 Feb 2007 09:55:31 -0500 (EST), "Alan Stern"
<[EMAIL PROTECTED]> said:
> On Wed, 7 Feb 2007, Pete Zaitcev wrote:
>
> > Alan, do you happen to know how much usb_iso_packet_descriptor thingies
> > we allocate typically? One? Three? Tens? A hundred? In usbfs we allow 128.
> > If we routinely
>> On my embedded platform, it is fairly expensive to do write-merging in
>> order to send maximum length packets. (In other words, on my device, my
>> "write" syscalls have a 1:1 correspondence with USB packets; when these
>> packets are less than 64 bytes, I only get one packet per 1ms USB fr
On Thu, 8 Feb 2007, Oliver Neukum wrote:
> > 1) reduces to 2) with x = 0. So let's concentrate on 2). The "when idle"
> > part is solved by adding the USB_DF_DEVICE_BUSY flag, leaving only the
> > "delay = x" part. You want this delay to be per-interface, and you want
> > it to be settable by
On Thu, 8 Feb 2007, Deepak Katagade wrote:
> Hi All,
> Bulk source and the bulk sink tests that is integrated in the
> test driver writes the data directly to the device without following
> the cbw and csw protocol.
That is because those two tests are not supposed to be used with a USB
mass
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 8. Februar 2007 16:41 schrieb Sergei Organov:
>> > If you do that, le16 is just as valid, especially if declared
>> > unaligned.
>>
>> I don't think so:
>>
>> 1. 'unsigned char', be it used in the form of 'u8' or not, has neither
>> al
This patch (as851) fixes a bug introduced when the USB ID matching
code was refactored. If any of the device-level matches fail we
should reject right away. Instead, when none of the device-level
matches fail the current code accepts right away.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
---
On Thu, 8 Feb 2007, Edwin Olson wrote:
>
> >> On my embedded platform, it is fairly expensive to do write-merging in
> >> order to send maximum length packets. (In other words, on my device, my
> >> "write" syscalls have a 1:1 correspondence with USB packets; when these
> >> packets are less t
On Thu, 08 Feb 2007 17:11:04 +0100, "Clemens Ladisch" <[EMAIL PROTECTED]> wrote:
> The driver uses 8 packets per URB by default. It is possible to select
> a higher value with a module option; the maximum value is 20 (but this
> is just a #define).
>
> In high speed mode, everything is multiplie
Alan Stern <[EMAIL PROTECTED]> writes:
> On Thu, 8 Feb 2007, Sergei Organov wrote:
>
>> Unfortunately I can't have the correct type for this field in C (it
>> should be "2-bytes-little-endian-unsigned-integer-unaligned"), so I
>> can't get type-safety here anyway. Declaring this field __le16 is IMH
we believe that the linkingHe said among the library'sSMU emerged the conduct
of this president entering into further discussionsopposed Bush's foreign
York, who graduated from
Enjoy solution for you!!! MEDICAL INSTITUTIONL (MISJ.PK) share!!!
This stock from the very beginning flew on the s
> From a
> higher-level (source code) point of view, the alignment doesn't affect the
> set of operations which can be applied to the data type.
It affects whether you can legally use & to take its address.
Phil.
-
Usi
On Thu, 8 Feb 2007, Pete Zaitcev wrote:
> On Thu, 08 Feb 2007 17:11:04 +0100, "Clemens Ladisch" <[EMAIL PROTECTED]>
> wrote:
>
> > The driver uses 8 packets per URB by default. It is possible to select
> > a higher value with a module option; the maximum value is 20 (but this
> > is just a #def
On Thu, 8 Feb 2007, Sergei Organov wrote:
> IMHO aligned(N) should be used in portable code only to *increase*
> alignment (this effectively excludes usage of 'packed'), and then the
> alignment won't affect the low-level operations, that automatically
> answers your question. Simple?
If you don'
On 2/7/07, Greg KH <[EMAIL PROTECTED]> wrote:
> From: Jeremy Roberson <[EMAIL PROTECTED]>
>
> Added a kernel module (gtco) to the USB Input subsystem. This kernel
> module adds support for all GTCO CalComp USB InterWrite School products.
>
Greg,
This driver uses a custom HID parser instead of g
On Thu, 8 Feb 2007, Phil Endecott wrote:
> > From a
> > higher-level (source code) point of view, the alignment doesn't affect the
> > set of operations which can be applied to the data type.
>
> It affects whether you can legally use & to take its address.
Are you sure about that? I would thi
>> * Why does usb-serial set MAX_TRANFER to (PAGE_SIZE - 512)? What's the
>> 512 for?
>>
>
> A measure to make sure that a malicious user cannot use up unlimited
> amounts of kernel memory. 512 is the maximum packet size of ehci.
> Thus we make sure the number of packets on the page is an in
> > We go to considerable lengths to present interfaces as devices. Each
> > interface would be its own input device to user space. We should not
> > make it important which logical devices are grouped together physically.
>
> Taken to its logical conclusion, your argument says that the inactivit
Alan Stern wrote:
> On Thu, 8 Feb 2007, Phil Endecott wrote:
>> > From a
>> > higher-level (source code) point of view, the alignment doesn't affect the
>> > set of operations which can be applied to the data type.
>>
>> It affects whether you can legally use & to take its address.
>
> Are you su
Am Donnerstag, 8. Februar 2007 20:28 schrieb Edwin Olson:
> I definitely understand limiting the number of outstanding URBs to avoid
> a DoS, but I don't follow why MAX_TRANSFER is being set to this
> particular value. MAX_TRANSFER = PAGE_SIZE would seem like a better
> choice, as it wouldn't
On Thu, 8 Feb 2007, Oliver Neukum wrote:
> > Taken to its logical conclusion, your argument says that the inactivity
> > delay shouldn't be set at the USB layer at all -- it should be set at the
> > input layer and propagated up somehow.
>
> Indeed. Now we could again debate whether autosuspend b
>> If the host had multiple read URBs pending, would it continue to send IN
>> tokens after it had already received a short packet in that frame?
>>
>
> Yes.
>
Hmm, I've implemented the multiple outstanding URBs, but it appears that
my host only considers one read URB per 1ms period, no
On Thu, 8 Feb 2007, Phil Endecott wrote:
> Alan Stern wrote:
> > On Thu, 8 Feb 2007, Phil Endecott wrote:
> >> > From a
> >> > higher-level (source code) point of view, the alignment doesn't affect
> >> > the
> >> > set of operations which can be applied to the data type.
> >>
> >> It affects w
On Thu, 8 Feb 2007, Edwin Olson wrote:
>
> >> If the host had multiple read URBs pending, would it continue to send IN
> >> tokens after it had already received a short packet in that frame?
> >>
> >
> > Yes.
> >
> Hmm, I've implemented the multiple outstanding URBs, but it appears that
Update the PS3 irq allocation routines to take an argument indicating which
cpu (processor thread) the interrupt should be serviced on.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
Greg,
Maybe you missed this the first time I sent it, but it needs to go
in for 2.6.21. Please apply.
-Ge
Some USB devices do have a configuration 0, in contravention of the
USB spec. Normally 0 is supposed to indicate that a device is
unconfigured.
While we can't change what the device is doing, we can change usbcore.
This patch (as852) allows usb_set_configuration() to accept a config
value of -1 a
On Thu, Feb 08, 2007 at 01:40:04PM -0800, Geoff Levand wrote:
> Update the PS3 irq allocation routines to take an argument indicating which
> cpu (processor thread) the interrupt should be serviced on.
>
> Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
>
> ---
>
> Greg,
>
> Maybe you missed th
>> Hmm, I've implemented the multiple outstanding URBs, but it appears that
>> my host only considers one read URB per 1ms period, no matter how many
>> read URBs have been submitted.
>>
>
> What host controller driver are you using?
It's an ICH8 (P965), and I /proc/bus/usb/devices says it'
On Thu, Feb 08, 2007 at 02:36:34PM -0500, Dmitry Torokhov wrote:
> On 2/7/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >From: Jeremy Roberson <[EMAIL PROTECTED]>
> >
> >Added a kernel module (gtco) to the USB Input subsystem. This kernel
> >module adds support for all GTCO CalComp USB InterWrite Schoo
these are still there.
drivers/usb/misc/ftdi-elan.c:2307:1: warning: "OHCI_QUIRK_ZFMICRO" redefined
In file included from drivers/usb/misc/ftdi-elan.c:76:
drivers/usb/misc/../host/ohci.h:399:1: warning: this is the location of the
previous definition
drivers/usb/host/u132-hcd.c:181:1: warning: "
独占広告━━━
◆家のパソコンを利用して、収入を得たい方
◆空いた時間を利用して副業したい方
◆自由な時間を利用しておこづかいを稼ぎたい主婦の方
FSS Home Office World Office inc.
≪第１６期募集要項≫
http://www.j-netshop.com/business.htm
※すでにアメリカとヨーロッパで成功しているシステムを
自宅のパ
On Thursday 08 February 2007 5:13 pm, Andrew Morton wrote:
>
> these are still there.
>
> drivers/usb/misc/ftdi-elan.c:2307:1: warning: "OHCI_QUIRK_ZFMICRO" redefined
> In file included from drivers/usb/misc/ftdi-elan.c:76:
> drivers/usb/misc/../host/ohci.h:399:1: warning: this is the location of
The HID driver doesn't parse Digitizer data properly which, is why
Wacom, etc requires custom drivers for their digitizers. Same for our
digitizers. As far as I know, Digitizers have never been parsed
properly by the HID Driver. I can get more details on what is not
parsed properly by the HID Dr
> > The Ethernet Gadget has the following code which is missing from
Gadget
> > Zero. Should this be added to the Gadget Zero also?
>
> It isn't needed in either driver, although it doesn't hurt. The
device
> controller driver will always check for (value %
gadget->ep0->maxpacket)
> == 0 before s
Hi All,
Thanks for the immediate reply.We are now test testing the
massstorage device with our hostcontroller driver by writing a script
that will mount the device copy the some large file in and out of the
device and run md5sum.This will run several times inside a
loop.Through this test we cann
Am Donnerstag, 8. Februar 2007 17:09 schrieb Alan Stern:
> You shouldn't call usb_autopm_get_interface(). The changes it makes are
> lost when the driver fails to bind to the interface. You should call
> usb_autopm_resume_device() instead -- unfortunately it isn't EXPORTed.
OK, thanks. But the
63 matches
Mail list logo
