rt_number, bytes);
usb_serial_debug_data(&port->dev,
__func__, bytes, urb->transfer_buffer);
urb->dev = serial->dev;
urb->transfer_buffer_length = bytes;
/* sent urb to USB-RSA */
//retval = usb_submit_urb(urb, GFP_ATOMIC);
..
Thanks
Tilman
28.665801] usbrsa ttyUSB0: usbrsa_close - end
[106428.665824] usbrsa ttyUSB0: usbrsa_status_callback(): wake_up
... (stty returns to command line. return code = 130)
SOURCE CODE:
/*
* Driver for IO-Data's USB RSA serial dongle
* Copyright (C) 2012
* Tilman Glotzner(tilmanglotz...@g
ttyUSB0
300 seems never to finish, while echo "0123456789" > /dev/ttyUSB0
reproducibly finish after 30 seconds. I will post the complete source code
in response to Greg's posting.
Tilman
= syslog ==
sbrsa_write; private struct =880307620e00
{103936.132220] usbrsa ttyUS
erial_port_softint?
Many thanks
Tilman
Syslog:
===
...
[ 7315.882626] usbrsa_open - port=0
[ 7315.882666] usbrsa ttyUSB0: usbrsa_write_room(): Pool=640;usbrsa.tx=4084
[ 7315.882673] usbrsa ttyUSB0: usbrsa_write - port 0 START
[ 7315.882676] usbrsa_write; private struct =8803ff468c00
[ 7315.88
rial_port_softint is intented to do.
Many thanks
Tilman
[ 7315.882927] usbrsa ttyUSB0: usbrsa_write_callback - length = 2, data = 0d 0a
[ 7315.882932] usbrsa ttyUSB0: usbrsa_write_callback(): Returned URB 1
[ 7315.882938] usbrsa_status_callback: nofTxBytesFree=4074,nofRxBytesRecei
there any limitations known, for
instance when using the usb_get_serial_port_data in an SMP environment? Any
suggestions in which direction to dig?
Thanks Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
0a f3 90 41 8b 40 08 85 c0 74 f6
RIP [] native_queued_spin_lock_slowpath+0x104/0x190
RSP
CR2: 1ddc00017654
---[ end trace a78fe1b9025ad592 ]---
BUG: unable to handle kernel paging request at ffd8
Many thanks
Tilman
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Greg KH writes:
>
> On Fri, Feb 19, 2016 at 06:49:50AM +, tilman wrote:
> > Hello
> >
> > I configured and setup a more recent kernel: V4.5.0-rc4
> >
> > The driver compiles and inserts.
>
> What driver? You have provided no context here :(
with BUG. Probably a null
pointer dereference...
Cheers
Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Greg KH writes:
>
> On Mon, Feb 15, 2016 at 11:30:43PM +, tilman wrote:
> > Dear all
> >
> > a couple of years ago I wrote a driver for a serial dongle.
> > I did not add it to the linux source because the dongle requires a firmware
> > to be downl
offer to use the module_init
function any longer.
What would be the appropriate place the corresponding request_module commands?
Many thanks
Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordo
ed by the normal slew of "new device found" messages.
>
> Git bisect points to this commit:
> f7965c0846d74b270e246c1470ca955d5078eb07
Here's another regression report pointing to that same commit:
http://lkml.org/lkml/2013/1/28/546
"external HDD in USB3 enclosure c
That would be an easy
> way to bring it up to modern standards, and fix the tty port issue at
> the same time.
I got the driver working to the extend it was working before. The issue was a
pointer dereferencing issue in the allocation routine. Thanks for the advice.
Tilman
--
To unsu
list.
Btw. are there repositories that would be suitable to make highly experimental
code available ?
Thanks
Tilman
/* File: usbrsatest.c
* Driver for IO-Data's USB RSA serial dongle (test driver)
* Copyright (C) 2012
* Tilman Glotzner
*
*
* This program is free sof
e system log or using
dmesg. Am i looking into the wrong files ?
Thanks
Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
else
{
release_status_urb(priv);
release_write_urb(priv);
release_read_urb(priv);
kfree(priv);
}
}
}
Thanks
Tilman
--
To unsubscribe from this
Peter Stuge writes:
> Tilman wrote:
> What device is that? Is it a Cypress FX2 or an SiLabs C8051?
ezusb (Cypress AN2131)
> > The urb eventually times out. Via debug FS I can see that the urb is
> > indeed submitted. I suspect the firmware to be responsible for this.
>
Tilman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ed by int_in_work() this might cause
int_in_work() to run after the post_reset method, with urb_int_in
already resubmitted, so handle that case gracefully.
Signed-off-by: Tilman Schmidt
---
drivers/isdn/gigaset/bas-gigaset.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
Am 13.10.2012 05:01, schrieb Ming Lei:
> On Sat, Oct 13, 2012 at 6:11 AM, Tilman Schmidt wrote:
>>
>> There are two cases I have to worry about:
>> (1) a reset triggered by int_in_work()
>> (2) a reset triggered by some other source external to the driver
>>
>&
Am 12.10.2012 16:17, schrieb Ming Lei:
> On Fri, Oct 12, 2012 at 5:26 PM, Tilman Schmidt wrote:
>
>> At first sight, I can simply omit the cancel_work_sync() in
>> the pre_reset() case. In the worst case, the uncancelled
>> int_in_work() will call usb_clear_halt(), try to
he worst case, the uncancelled
int_in_work() will call usb_clear_halt(), try to resubmit the
already submitted URB, fail, and trigger another reset
needlessly. Doesn't sound too bad?
The alternative would be to introduce a new flag in the device
state to skip the cancel_work_sync() ca
and not just "usb-serial:" instead ?
Easier coding - or rather, avoiding the work of re-coding. The info()
macro
is there, it works, why change it?
> can this probable be optimized (as most drivers only print "drivername:"
> anyway) ?
See the redefinition of these
23 matches
Mail list logo