Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote:
> > I started in the morning to build the driver from the source provided
> > by the vendor, but it was written in the times of kernel-version 2.4,
> > and I got hopelessly stuck.
>
> The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
http://www.wch.cn/downfile/177
The vendor driver version 1.2 readme.txt from 2014-10-10 says:
Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x
It didn't build immediately against the kernel I had at hand, but with
a small touchup (patch attached) it built fine against a 3.10 kernel.
> > Also, as per
> > http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
> > the particular serial-USB-adapter device is added into the id_table,
> > so seems supported as per say.
>
> That id was added by 82078234d402 ("USB: serial: ch341: New VID/PID for
> CH341 USB-serial") in 2008, which claims that the driver supports both
> old and new devices.
My hardware has that same VID/PID, but there is a version request
sent to the device and my version number is quite a bit higher (20-30)
than what is mentioned in the in-tree driver comments; I guess the
protocol grew with newer versions of the device, but VID/PID weren't
updated. I'm sure it's possible to have a backwards-compatible
driver, but the vendor driver differs enough from the in-tree driver
that I can't be confident that simply doing what the vendor driver
does will work also on older versions of the device.
> > ###
> > usb 2-2: device not accepting address 8, error -71
> > ###
>
> This still looks like a hardware issue to me. Specifically, this happens
> before the ch341 driver is even involved.
I haven't seen any messages like this with my hardware.
//Peter
--- ch34x.c.orig2014-04-14 10:38:44.0 +0200
+++ ch34x.c 2015-06-15 19:26:39.0 +0200
@@ -10,11 +10,7 @@
// Support linux kernel version 2.6.25 and later
//
-#include
-#ifndef KERNEL_VERSION
-#defineKERNEL_VERSION(ver, rel, seq) ((ver << 16) | (rel << 8) |
(seq))
-#endif
-
+#include
#include
#include
#include
@@ -380,7 +376,7 @@
unsigned char reg_value = 0;
unsigned short value = 0;
unsigned short index = 0;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -405,7 +401,7 @@
return;
cflag = termios->c_cflag;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s (%d) cflag=0x%x\n", __func__, port->number, cflag);
#else
dbg_ch34x("%s (%d) cflag=0x%x\n", __func__, port->port_number, cflag);
@@ -515,7 +511,7 @@
/*unsigned int msr;*/
unsigned int retval;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -561,7 +557,7 @@
long timeout;
wait_queue_t wait;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -636,7 +632,7 @@
struct usb_serial *serial = port->serial;
int retval;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number );
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number );
@@ -710,7 +706,7 @@
/*unsigned int mcr = priv->line_control;*/
u8 control;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d", __func__, port->number);
#else
dbg_ch34x("%s - port:%d", __func__, port->port_number);
@@ -743,7 +739,7 @@
unsigned int status;
unsigned int changed;
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s -port:%d", __func__, port->number);
#else
dbg_ch34x("%s -port:%d", __func__, port->port_number);
@@ -793,7 +789,7 @@
{
//struct usb_serial_port *port = tty->driver_data;
#endif
-#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE < KERNEL_VERSION(3, 11, 0))
dbg_ch34x("%s - port:%d, cmd=0x%04x", __func__, port->number, cmd);
#else
dbg_ch34x("%s - port:%d, cmd=0x%04x", __func__, port->port_number, cmd);
@@ -802,7 +798,7 @@
{
// Note here
case TIOCMIWAIT:
Re: Likely issue with ch341 kernel-module/driver
On Thu, Aug 27, 2015 at 01:57:01PM +0530, Ajay Garg wrote: > Hi John. > > On Thu, Aug 27, 2015 at 1:07 PM, Johan Hovold wrote: > > > > Try to see if you can get the device to work reliably with some other > > driver (vendor driver or other OS) to rule out a broken device. > > > > I tested the serial-usb adapter using a loopback-hardware-tool > (confirmed to be perfect). > > Using this, I see what I type, echo it back, and see what I receive. > > The putty session-settings are standard one - 9600, 8N-1, no parity. > > The byte flow is > putty-on-laptop => usb-interface => serial-interface => loopback => > serial-interface => usb-interface => putty-on-laptop. > > Thereafter, following are the echo-sequences I see :: > > a ==> 0 > b ==> ' > c ==> N > > This (I guess) confirms a problem on (at least) the driver-side. Not unless you confirm that the same setup works when using a different driver, right? Otherwise, it could still be a hw issue. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Hi John. On Thu, Aug 27, 2015 at 1:07 PM, Johan Hovold wrote: > > Try to see if you can get the device to work reliably with some other > driver (vendor driver or other OS) to rule out a broken device. > I tested the serial-usb adapter using a loopback-hardware-tool (confirmed to be perfect). Using this, I see what I type, echo it back, and see what I receive. The putty session-settings are standard one - 9600, 8N-1, no parity. The byte flow is putty-on-laptop => usb-interface => serial-interface => loopback => serial-interface => usb-interface => putty-on-laptop. Thereafter, following are the echo-sequences I see :: a ==> 0 b ==> ' c ==> N This (I guess) confirms a problem on (at least) the driver-side. Thanks everyone for the quick replies so far, I am grateful. Thanks and Regards, Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
[ Please avoid top-posting. ]
On Thu, Aug 27, 2015 at 12:13:32PM +0530, Ajay Garg wrote:
> I started in the morning to build the driver from the source provided
> by the vendor, but it was written in the times of kernel-version 2.4,
> and I got hopelessly stuck.
The vendor driver is only for 2.4? Peter?
> Wanting to take a break, I reset my setup, and VERY strangely, what I
> now observe is ::
>
> a)
> I am NOT able to send anything from the embedded-system to
> putty-session (nothing appears at all on the putty session).
>
> b)
> Receive is working perfectly (anything I type in the putty-session is
> received fine in the embedded-application).
>
>
> Not sure what the hell is going on :(
Did you enable hardware flow control somewhere perhaps?
> Also, as per
> http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
> the particular serial-USB-adapter device is added into the id_table,
> so seems supported as per say.
That id was added by 82078234d402 ("USB: serial: ch341: New VID/PID for
CH341 USB-serial") in 2008, which claims that the driver supports both
old and new devices.
> Additionally, the message has changed to
>
> ###
> usb 2-2: device not accepting address 8, error -71
> ###
This still looks like a hardware issue to me. Specifically, this happens
before the ch341 driver is even involved.
> Completely lost :(
Try to see if you can get the device to work reliably with some other
driver (vendor driver or other OS) to rule out a broken device.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
I started in the morning to build the driver from the source provided by the vendor, but it was written in the times of kernel-version 2.4, and I got hopelessly stuck. Wanting to take a break, I reset my setup, and VERY strangely, what I now observe is :: a) I am NOT able to send anything from the embedded-system to putty-session (nothing appears at all on the putty session). b) Receive is working perfectly (anything I type in the putty-session is received fine in the embedded-application). Not sure what the hell is going on :( Also, as per http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16, the particular serial-USB-adapter device is added into the id_table, so seems supported as per say. Additionally, the message has changed to ### usb 2-2: device not accepting address 8, error -71 ### Completely lost :( On Wed, Aug 26, 2015 at 11:45 PM, Johan Hovold wrote: > On Wed, Aug 26, 2015 at 08:09:30PM +0200, Peter Stuge wrote: >> Johan Hovold wrote: >> > On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: >> .. >> > > garbage characters transmitted from embedded-device >> .. >> > > It seems that there is some issue with the driver. >> > >> > Why do think it's a driver issue? >> >> I can confirm similar issues with the in-tree driver and my hardware. > > What hardware is that? > >> > > Any chance this can be made to work? >> >> Ajay, please try building the vendor driver. That works well for me. > > Yes, please do. > >> > > Any upgrade that might solve the issue? >> >> There is no upgrade. Someone needs to spend a day or so on adding >> functionality from the vendor driver to the in-tree driver, in a >> backwards-compatible way. >> >> > Looks like a hardware issue, I'm afraid. >> >> When I got garbage from the in-tree driver it was indeed a driver issue. > > That's good to hear. Care to write up a patch? :) > > Thanks, > Johan -- Regards, Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
On Thu, Aug 27, 2015 at 01:57:01PM +0530, Ajay Garg wrote: Hi John. On Thu, Aug 27, 2015 at 1:07 PM, Johan Hovold jo...@kernel.org wrote: Try to see if you can get the device to work reliably with some other driver (vendor driver or other OS) to rule out a broken device. I tested the serial-usb adapter using a loopback-hardware-tool (confirmed to be perfect). Using this, I see what I type, echo it back, and see what I receive. The putty session-settings are standard one - 9600, 8N-1, no parity. The byte flow is putty-on-laptop = usb-interface = serial-interface = loopback = serial-interface = usb-interface = putty-on-laptop. Thereafter, following are the echo-sequences I see :: a == 0 b == ' c == N This (I guess) confirms a problem on (at least) the driver-side. Not unless you confirm that the same setup works when using a different driver, right? Otherwise, it could still be a hw issue. Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
I started in the morning to build the driver from the source provided by the vendor, but it was written in the times of kernel-version 2.4, and I got hopelessly stuck. Wanting to take a break, I reset my setup, and VERY strangely, what I now observe is :: a) I am NOT able to send anything from the embedded-system to putty-session (nothing appears at all on the putty session). b) Receive is working perfectly (anything I type in the putty-session is received fine in the embedded-application). Not sure what the hell is going on :( Also, as per http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16, the particular serial-USB-adapter device is added into the id_table, so seems supported as per say. Additionally, the message has changed to ### usb 2-2: device not accepting address 8, error -71 ### Completely lost :( On Wed, Aug 26, 2015 at 11:45 PM, Johan Hovold jo...@kernel.org wrote: On Wed, Aug 26, 2015 at 08:09:30PM +0200, Peter Stuge wrote: Johan Hovold wrote: On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. garbage characters transmitted from embedded-device .. It seems that there is some issue with the driver. Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. What hardware is that? Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. Yes, please do. Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. That's good to hear. Care to write up a patch? :) Thanks, Johan -- Regards, Ajay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
[ Please avoid top-posting. ] On Thu, Aug 27, 2015 at 12:13:32PM +0530, Ajay Garg wrote: I started in the morning to build the driver from the source provided by the vendor, but it was written in the times of kernel-version 2.4, and I got hopelessly stuck. The vendor driver is only for 2.4? Peter? Wanting to take a break, I reset my setup, and VERY strangely, what I now observe is :: a) I am NOT able to send anything from the embedded-system to putty-session (nothing appears at all on the putty session). b) Receive is working perfectly (anything I type in the putty-session is received fine in the embedded-application). Not sure what the hell is going on :( Did you enable hardware flow control somewhere perhaps? Also, as per http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16, the particular serial-USB-adapter device is added into the id_table, so seems supported as per say. That id was added by 82078234d402 (USB: serial: ch341: New VID/PID for CH341 USB-serial) in 2008, which claims that the driver supports both old and new devices. Additionally, the message has changed to ### usb 2-2: device not accepting address 8, error -71 ### This still looks like a hardware issue to me. Specifically, this happens before the ch341 driver is even involved. Completely lost :( Try to see if you can get the device to work reliably with some other driver (vendor driver or other OS) to rule out a broken device. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Hi John. On Thu, Aug 27, 2015 at 1:07 PM, Johan Hovold jo...@kernel.org wrote: Try to see if you can get the device to work reliably with some other driver (vendor driver or other OS) to rule out a broken device. I tested the serial-usb adapter using a loopback-hardware-tool (confirmed to be perfect). Using this, I see what I type, echo it back, and see what I receive. The putty session-settings are standard one - 9600, 8N-1, no parity. The byte flow is putty-on-laptop = usb-interface = serial-interface = loopback = serial-interface = usb-interface = putty-on-laptop. Thereafter, following are the echo-sequences I see :: a == 0 b == ' c == N This (I guess) confirms a problem on (at least) the driver-side. Thanks everyone for the quick replies so far, I am grateful. Thanks and Regards, Ajay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote:
I started in the morning to build the driver from the source provided
by the vendor, but it was written in the times of kernel-version 2.4,
and I got hopelessly stuck.
The vendor driver is only for 2.4? Peter?
http://www.wch.cn/download/CH341SER_LINUX_ZIP.html
http://www.wch.cn/downfile/177
The vendor driver version 1.2 readme.txt from 2014-10-10 says:
Current Driver support versions of linux kernel range from 2.6.25 to 3.13.x
It didn't build immediately against the kernel I had at hand, but with
a small touchup (patch attached) it built fine against a 3.10 kernel.
Also, as per
http://lxr.free-electrons.com/source/drivers/usb/serial/ch341.c?v=3.16,
the particular serial-USB-adapter device is added into the id_table,
so seems supported as per say.
That id was added by 82078234d402 (USB: serial: ch341: New VID/PID for
CH341 USB-serial) in 2008, which claims that the driver supports both
old and new devices.
My hardware has that same VID/PID, but there is a version request
sent to the device and my version number is quite a bit higher (20-30)
than what is mentioned in the in-tree driver comments; I guess the
protocol grew with newer versions of the device, but VID/PID weren't
updated. I'm sure it's possible to have a backwards-compatible
driver, but the vendor driver differs enough from the in-tree driver
that I can't be confident that simply doing what the vendor driver
does will work also on older versions of the device.
###
usb 2-2: device not accepting address 8, error -71
###
This still looks like a hardware issue to me. Specifically, this happens
before the ch341 driver is even involved.
I haven't seen any messages like this with my hardware.
//Peter
--- ch34x.c.orig2014-04-14 10:38:44.0 +0200
+++ ch34x.c 2015-06-15 19:26:39.0 +0200
@@ -10,11 +10,7 @@
// Support linux kernel version 2.6.25 and later
//
-#include linux/version.h
-#ifndef KERNEL_VERSION
-#defineKERNEL_VERSION(ver, rel, seq) ((ver 16) | (rel 8) |
(seq))
-#endif
-
+#include generated/uapi/linux/version.h
#include linux/kernel.h
#include linux/errno.h
#include linux/init.h
@@ -380,7 +376,7 @@
unsigned char reg_value = 0;
unsigned short value = 0;
unsigned short index = 0;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -405,7 +401,7 @@
return;
cflag = termios-c_cflag;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s (%d) cflag=0x%x\n, __func__, port-number, cflag);
#else
dbg_ch34x(%s (%d) cflag=0x%x\n, __func__, port-port_number, cflag);
@@ -515,7 +511,7 @@
/*unsigned int msr;*/
unsigned int retval;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -561,7 +557,7 @@
long timeout;
wait_queue_t wait;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -636,7 +632,7 @@
struct usb_serial *serial = port-serial;
int retval;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number );
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number );
@@ -710,7 +706,7 @@
/*unsigned int mcr = priv-line_control;*/
u8 control;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, __func__, port-number);
#else
dbg_ch34x(%s - port:%d, __func__, port-port_number);
@@ -743,7 +739,7 @@
unsigned int status;
unsigned int changed;
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s -port:%d, __func__, port-number);
#else
dbg_ch34x(%s -port:%d, __func__, port-port_number);
@@ -793,7 +789,7 @@
{
//struct usb_serial_port *port = tty-driver_data;
#endif
-#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 10, 0))
+#if(LINUX_VERSION_CODE KERNEL_VERSION(3, 11, 0))
dbg_ch34x(%s - port:%d, cmd=0x%04x, __func__, port-number, cmd);
#else
dbg_ch34x(%s - port:%d, cmd=0x%04x, __func__, port-port_number, cmd);
@@ -802,7 +798,7 @@
{
// Note here
case TIOCMIWAIT:
-#if(LINUX_VERSION_CODE
Re: Likely issue with ch341 kernel-module/driver
On Wed, Aug 26, 2015 at 08:09:30PM +0200, Peter Stuge wrote: > Johan Hovold wrote: > > On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: > .. > > > garbage characters transmitted from embedded-device > .. > > > It seems that there is some issue with the driver. > > > > Why do think it's a driver issue? > > I can confirm similar issues with the in-tree driver and my hardware. What hardware is that? > > > Any chance this can be made to work? > > Ajay, please try building the vendor driver. That works well for me. Yes, please do. > > > Any upgrade that might solve the issue? > > There is no upgrade. Someone needs to spend a day or so on adding > functionality from the vendor driver to the in-tree driver, in a > backwards-compatible way. > > > Looks like a hardware issue, I'm afraid. > > When I got garbage from the in-tree driver it was indeed a driver issue. That's good to hear. Care to write up a patch? :) Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote: > On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. > > garbage characters transmitted from embedded-device .. > > It seems that there is some issue with the driver. > > Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. > > Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. > > Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. > Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
[ +CC: linux-usb ] On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: > Hi all. > > I am attaching the RS232-TTL via a serial-USB converter on my machine. > > However, when I connect a putty-session with my embedded-device, I see > strange issues (garbage characters transmitted from embedded-device to > putty; nothing can be read from putty into embedded-device). > > It seems that there is some issue with the driver. Why do think it's a driver issue? > Lots of these lines are seen in dmesg :: > > > > [ 8657.022997] ch341-uart ttyUSB0: > usb_serial_generic_read_bulk_callback - nonzero urb status: -71 > > > > > Other informations :: > > > ajay@ajay-HP-15-Notebook-PC:~$ lsusb > Bus 001 Device 002: ID 8087:8001 Intel Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 002 Device 003: ID 05c8:036e Cheng Uei Precision Industry Co., Ltd > (Foxlink) > Bus 002 Device 002: ID 0bda:b001 Realtek Semiconductor Corp. > Bus 002 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > > > ajay@ajay-HP-15-Notebook-PC:~$ lsmod | grep ch341 > ch341 13761 1 > usbserial 38972 3 ch341 > > > > > ajay@ajay-HP-15-Notebook-PC:~$ uname -a > Linux ajay-HP-15-Notebook-PC 3.16.0-30-generic #40~14.04.1-Ubuntu SMP > Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux > > > > > Any chance this can be made to work? Any upgrade that might solve the issue? > We will be grateful for ideas. This is a known issue with your device that has been reported in this thread: https://lkml.kernel.org/r/caf3ayyde44pod1nosbqn_gja8xlok3r_getdynwx+a_1rl0...@mail.gmail.com Looks like a hardware issue, I'm afraid. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Likely issue with ch341 kernel-module/driver
Hi all. I am attaching the RS232-TTL via a serial-USB converter on my machine. However, when I connect a putty-session with my embedded-device, I see strange issues (garbage characters transmitted from embedded-device to putty; nothing can be read from putty into embedded-device). It seems that there is some issue with the driver. Lots of these lines are seen in dmesg :: [ 8657.022997] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 Other informations :: ajay@ajay-HP-15-Notebook-PC:~$ lsusb Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 003: ID 05c8:036e Cheng Uei Precision Industry Co., Ltd (Foxlink) Bus 002 Device 002: ID 0bda:b001 Realtek Semiconductor Corp. Bus 002 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ajay@ajay-HP-15-Notebook-PC:~$ lsmod | grep ch341 ch341 13761 1 usbserial 38972 3 ch341 ajay@ajay-HP-15-Notebook-PC:~$ uname -a Linux ajay-HP-15-Notebook-PC 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux Any chance this can be made to work? Any upgrade that might solve the issue? We will be grateful for ideas. Thanks and Regards, Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
Johan Hovold wrote: On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. garbage characters transmitted from embedded-device .. It seems that there is some issue with the driver. Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
On Wed, Aug 26, 2015 at 08:09:30PM +0200, Peter Stuge wrote: Johan Hovold wrote: On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: .. garbage characters transmitted from embedded-device .. It seems that there is some issue with the driver. Why do think it's a driver issue? I can confirm similar issues with the in-tree driver and my hardware. What hardware is that? Any chance this can be made to work? Ajay, please try building the vendor driver. That works well for me. Yes, please do. Any upgrade that might solve the issue? There is no upgrade. Someone needs to spend a day or so on adding functionality from the vendor driver to the in-tree driver, in a backwards-compatible way. Looks like a hardware issue, I'm afraid. When I got garbage from the in-tree driver it was indeed a driver issue. That's good to hear. Care to write up a patch? :) Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Likely issue with ch341 kernel-module/driver
[ +CC: linux-usb ] On Wed, Aug 26, 2015 at 09:39:36PM +0530, Ajay Garg wrote: Hi all. I am attaching the RS232-TTL via a serial-USB converter on my machine. However, when I connect a putty-session with my embedded-device, I see strange issues (garbage characters transmitted from embedded-device to putty; nothing can be read from putty into embedded-device). It seems that there is some issue with the driver. Why do think it's a driver issue? Lots of these lines are seen in dmesg :: [ 8657.022997] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 Other informations :: ajay@ajay-HP-15-Notebook-PC:~$ lsusb Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 003: ID 05c8:036e Cheng Uei Precision Industry Co., Ltd (Foxlink) Bus 002 Device 002: ID 0bda:b001 Realtek Semiconductor Corp. Bus 002 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ajay@ajay-HP-15-Notebook-PC:~$ lsmod | grep ch341 ch341 13761 1 usbserial 38972 3 ch341 ajay@ajay-HP-15-Notebook-PC:~$ uname -a Linux ajay-HP-15-Notebook-PC 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux Any chance this can be made to work? Any upgrade that might solve the issue? We will be grateful for ideas. This is a known issue with your device that has been reported in this thread: https://lkml.kernel.org/r/caf3ayyde44pod1nosbqn_gja8xlok3r_getdynwx+a_1rl0...@mail.gmail.com Looks like a hardware issue, I'm afraid. Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Likely issue with ch341 kernel-module/driver
Hi all. I am attaching the RS232-TTL via a serial-USB converter on my machine. However, when I connect a putty-session with my embedded-device, I see strange issues (garbage characters transmitted from embedded-device to putty; nothing can be read from putty into embedded-device). It seems that there is some issue with the driver. Lots of these lines are seen in dmesg :: [ 8657.022997] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71 Other informations :: ajay@ajay-HP-15-Notebook-PC:~$ lsusb Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 003: ID 05c8:036e Cheng Uei Precision Industry Co., Ltd (Foxlink) Bus 002 Device 002: ID 0bda:b001 Realtek Semiconductor Corp. Bus 002 Device 011: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ajay@ajay-HP-15-Notebook-PC:~$ lsmod | grep ch341 ch341 13761 1 usbserial 38972 3 ch341 ajay@ajay-HP-15-Notebook-PC:~$ uname -a Linux ajay-HP-15-Notebook-PC 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux Any chance this can be made to work? Any upgrade that might solve the issue? We will be grateful for ideas. Thanks and Regards, Ajay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
