Alan Stern <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Sergei Organov wrote:
>
>> The fact remains that even GCC extensions to C can't deal with
>> endianness. I'd like to have such an extension though.
>
> It would be nice. And useful. It would al
Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 9 Feb 2007, Sergei Organov wrote:
>
>> Alan Stern <[EMAIL PROTECTED]> writes:
>>
>> > On Thu, 8 Feb 2007, Sergei Organov wrote:
>> >
>> >> IMHO aligned(N) should be used in portable code o
Alan Stern <[EMAIL PROTECTED]> writes:
> 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
Alan Stern <[EMAIL PROTECTED]> writes:
> 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
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-
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. 'unsig
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
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:
>>
>> &
David Brownell <[EMAIL PROTECTED]> writes:
> On Tuesday 06 February 2007 2:48 pm, Pete Zaitcev wrote:
>> On Tue, 6 Feb 2007 13:08:19 -0800, Inaky Perez-Gonzalez <[EMAIL PROTECTED]>
>> wrote:
>>
>> > [btw, I truly have little idea about which are those specific costs,
>> > out of professional cur
Pete Zaitcev <[EMAIL PROTECTED]> writes:
> 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(__u8 const *p)
>>
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 7. Februar 2007 15:04 schrieb Sergei Organov:
>> Unfortunately le16_to_cpu() is not exactly what's needed here, and if
>> I re-implement the above in terms of it:
>
> The issues of endianness and alignment ar
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 7. Februar 2007 14:31 schrieb Sergei Organov:
>
>> struct some_descriptor descr;
>> ...
>> read_from_wire(&descr, sizeof(descr));
>> do_something_with_values(usb_get_uint16(descr->foo), ba
Inaky Perez-Gonzalez <[EMAIL PROTECTED]> writes:
[...]
> Here is my point: it's way easier and more maintenable to do
>
> struct some_descriptor {
> __le16 foo;
> __u8 bar;
> } __attribute__((packed));
> ...
> struct some_descriptor descr;
>
Hello,
My Canon photo camera is visible on USB bus only when I'm root, and
invisible when I'm user:
[EMAIL PROTECTED] ~$ lsusb
Bus 001 Device 001: ID :
Bus 001 Device 002: ID 046d:c03d Logitech, Inc.
Bus 003 Device 001: ID :
Bus 004 Device 002: ID 0aec:3260 Neodio Technologies Cor
Naranjo Manuel Francisco <[EMAIL PROTECTED]> writes:
> My problems start when I recieve more than 300 bytes. The system crashes. I
> have
> tried to delay the output of data in order to give the hardware time to push
> the recived data out, but could get to anything.
> I'm not sending this as a pa
Greg KH <[EMAIL PROTECTED]> writes:
> On Thu, Jul 13, 2006 at 10:20:19PM +0400, Sergei Organov wrote:
[...]
>> Besides, if the throttle() is that important and failure to handle it is
>> a big mistake, why is it optional then? I mean why struct tty_operations
>> with th
Pete Zaitcev <[EMAIL PROTECTED]> writes:
> On Thu, 13 Jul 2006 16:31:35 +0400, Sergei Organov <[EMAIL PROTECTED]> wrote:
>
>> > The application will get a signal that the device has "hung up" which
>> > usually causes it to automatically close the file
Alan Cox <[EMAIL PROTECTED]> writes:
> On Iau, 2006-07-13 at 18:17 +0400, Sergei Organov wrote:
>> This problem may occur with any tty driver that doesn't stop to insert
>> data into the tty buffers in throttled state. And yes, there are such
>> drivers in the tree
Alan Cox <[EMAIL PROTECTED]> writes:
> Ar Llu, 2006-07-10 am 19:54 +0400, ysgrifennodd Sergei Organov:
>> Wow! The code you've quoted seems to be correct! But where did you get
>> it from? The version of flush_to_ldisc() from drivers/char/tty_io.c from
>> 2.17.4
"Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> writes:
> Hi Sergei,
>
> On Wed, 12 Jul 2006 15:42:14 +0400
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>
> | Suppose I have a usb-serial device managed, say, by the airprime
> | driver. When I connect i
Greg KH <[EMAIL PROTECTED]> writes:
> On Wed, Jul 12, 2006 at 03:42:14PM +0400, Sergei Organov wrote:
>> Suppose I have a usb-serial device managed, say, by the airprime
>> driver. When I connect it, it is attached to the /dev/ttyUSB0, then,
>> every disconnect/connec
Suppose I have a usb-serial device managed, say, by the airprime
driver. When I connect it, it is attached to the /dev/ttyUSB0, then,
every disconnect/connect results in detaching from /dev/ttyUSB0 and
attaching back to /dev/ttyUSB0 *unless* there is an application that
keeps an opened fd got from
Andy Gay <[EMAIL PROTECTED]> writes:
> On Tue, 2006-07-11 at 22:31 +0400, Sergei Organov wrote:
>> Andy Gay <[EMAIL PROTECTED]> writes:
[...]
>> > + /* something happened, so free up the memory for this urb /*
>>
>> There should be '*/&#x
Andy Gay <[EMAIL PROTECTED]> writes:
> Adapted from an earlier patch by Greg KH <[EMAIL PROTECTED]>.
> That patch added multiple read urbs and larger transfer buffers to allow
> data transfers at full EvDO speed.
Below are two more problems with the patch, one of which existed in the
original Greg
Alan Cox <[EMAIL PROTECTED]> writes:
> Ar Llu, 2006-07-10 am 19:54 +0400, ysgrifennodd Sergei Organov:
>> Wow! The code you've quoted seems to be correct! But where did you get
>> it from? The version of flush_to_ldisc() from drivers/char/tty_io.c from
>> 2.17.4
Alan Cox <[EMAIL PROTECTED]> writes:
> Ar Llu, 2006-07-10 am 14:36 +0400, ysgrifennodd Sergei Organov:
>> However, the problem is easily seen for USB-to-tty drivers where there
>> are no UARTS anywhere and speeds are rather high so that more than 4096
>> bytes (the
Alan Cox <[EMAIL PROTECTED]> writes:
> Ar Gwe, 2006-07-07 am 21:23 +0400, ysgrifennodd Sergei Organov:
>> It seems that there is much worse problem here. The amount of data that
>> has been inserted by the tty_insert_flip_string() could be up to
>> URB_TRANSFER_BUFFER
Greg KH <[EMAIL PROTECTED]> writes:
> On Fri, Jul 07, 2006 at 05:06:05PM +0400, Sergei Organov wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
>> > On Tue, Jul 04, 2006 at 09:46:09AM -0300, Manuel Naranjo wrote:
>> [...]
>> >> +#include <../drivers
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 30 Jun 2006 01:48:02 -0400
> Andy Gay <[EMAIL PROTECTED]> wrote:
[...]
>> +if (tty && urb->actual_length) {
>> +tty_buffer_request_room(tty, urb->actual_length);
>> +tty_insert_flip_string(tty, data, urb->actual_length)
Greg KH <[EMAIL PROTECTED]> writes:
> On Tue, Jul 04, 2006 at 09:46:09AM -0300, Manuel Naranjo wrote:
[...]
>> +#include <../drivers/usb/serial/usb-serial.h>
>
> Huh? It should just be "usb-serial.h"
I've just got similar trouble. It can't easily be just "usb-serial.h" if
you try to compile the m
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 30 Jun 2006 01:48:02 -0400
> Andy Gay <[EMAIL PROTECTED]> wrote:
[...]
>> +if (tty && urb->actual_length) {
>> +tty_buffer_request_room(tty, urb->actual_length);
>> +tty_insert_flip_string(tty, data, urb->actual_length)
Greg KH <[EMAIL PROTECTED]> writes:
> On Fri, Jun 16, 2006 at 08:05:20PM +0400, Sergei Organov wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
[...]
>> > This patch:
>> >
>> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregk
Greg KH <[EMAIL PROTECTED]> writes:
> On Tue, Jun 13, 2006 at 02:42:38PM +0400, Sergei Organov wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
[...]
>> > I've posted some patches here for the airprime driver that should be
>> > able to saturate the USB b
Greg KH <[EMAIL PROTECTED]> writes:
> On Thu, Jun 08, 2006 at 09:16:17AM +0400, Sergei Organov wrote:
>> Hi Luiz,
>>
>> "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> writes:
>> > Hi Sergei,
>> [...]
>> > I said 'curr
Hi Luiz,
"Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> writes:
> Hi Sergei,
[...]
> I said 'current design' because the generic code could be merged
> with usbserial core with the libata-like design we discussed
> some days ago (which is part of my Serial Core port WIP[1]).
>
> [1]
> http:/
Greg KH <[EMAIL PROTECTED]> writes:
> On Wed, Jun 07, 2006 at 12:27:03PM +0400, Sergei Organov wrote:
>> Greg KH <[EMAIL PROTECTED]> writes:
>> > On Mon, Jun 05, 2006 at 06:05:12PM +0400, Sergei Organov wrote:
>> >> Hello,
>> >>
>> &g
Greg KH <[EMAIL PROTECTED]> writes:
> On Mon, Jun 05, 2006 at 06:05:12PM +0400, Sergei Organov wrote:
>> Hello,
>>
>> I'm using usbserial module to talk to a device supporting 2 bulk
>> endpoints (high speed USB 1.1).
[...]
>
>> The input from t
Greg KH <[EMAIL PROTECTED]> writes:
> On Mon, Jun 05, 2006 at 06:05:12PM +0400, Sergei Organov wrote:
>> Hello,
>>
>> I'm using usbserial module to talk to a device supporting 2 bulk
>> endpoints (high speed USB 1.1).
>
> Which usb-serial driver are you
Hello,
I'm using usbserial module to talk to a device supporting 2 bulk
endpoints (high speed USB 1.1). The input from the device to the host is
OK. However, when I write a sequence containing CR and/or LF to the
device, the device sees fake 0x80 just before CR and/or LF, and I see
this fake 0x80
39 matches
Mail list logo
