Re: ch341

Can you actually trust that pl2303 module? They're not exactly known for being trouble free, and have often been cloned in the past as well, with varyings levels of success. Do you have a cp210x or ft23x at all? This is one of the great pitfalls of loopback testing, it doesn't test that anything

Re: [PATCH 2/4] USB: ch341: reinitialize chip on reconfiguration

his insistence that any patch trying to fix this driver somehow preserves all the existing undocumented, unexplained and _non-functioning_ bizarre lines of code is exhausting. There's been probably ~6 people now submit patches to this driver, all of which make marked useful improvements to a driver t

Re: [PATCH v3 06/13] USB: ch341: add support for parity, frame length, stop bits

Sorry if you get this twice, I was having some client problems, but wanted to make sure you got this one... Grigori Goronzy wrote: > With the new reinitialization method, configuring parity, > different frame lengths and different stop bit settings work as > expected on both

Re: [PATCH v2 14/14] USB: ch341: implement tx_empty callback

Grigori Goronzy wrote: > The status bit was found with USB captures of the Windows > driver and some luck. Tested on CH340G and CH341A. By my reversing, bit 0x4, is "multiple status changes since last interrupt" > > Signed-off-by: Grigori Goronzy > --- >

Re: [PATCH v2 07/14] USB: ch341: add support for parity, frame length, stop bits

Grigori Goronzy wrote: > With the new reinitialization method, configuring parity, > different frame lengths and different stop bit settings work as > expected on both CH340G and CH341A. This has been extensively > tested with a logic analyzer. > > Tested-by: Ryan Barber

Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > I admit I hadn't seen this earlier, and I didn't spend all day > > looking at previous attempts, but what's the motivation for > > putting all this overloaded syntax into the "brightness" file? I > > thought the point was to have a single value in

Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's

ghtness entry should do? I'd like to set the rgb colour of a led (or hsv, that can be it's own file too) and separately ramp the brightness up and down. I also think it's substantially simpler and easier to use from the user's point of view, which is surely the place you want e

Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Douglas Anderson wrote: > > + /* > + * Sleep for 10-15 ms after the reset to let it finish. > + * > + * It's been confirmed on at least one version of the controller > + * that this is a requirement

Re: [PATCH v4] USB: serial: cp210x: Adding GPIO support for CP2105

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martyn Welch wrote: > > > > The cp2105 is the only one of these devices that muxes GPIO > with serial control signals. The cp2102, cp2103 and cp2108 > provide both GPIO and serial control signals separately, so the >

Re: ch341: support new device types (Was: Re: PROBLEM: ch341 module fails with EPROTO when I plug-in Arduino board)

, but it's simply not a priority for me right now unfortunately. one day, one day... Sincerely, Karl Palsson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJVm7KIAAoJEBmotQ/U1cr2OH8P/A8/tWWNCRz6fgUtPxbmM73/ D272u1kTBC26PwOEN0Eb9gCAXEDk6xb7+1GcKTSzZ7v2LyAV9EbC/rfUw04+omLB

Re: Re: excessive usb traffic with FT230x

, I've now seen that this is actually happening with my ftdi ft232 devices on desktop linux too [1], but not for my cp210x, and not for a ch341 device If I'm not interested in modem status, can I disable this entirely? I don't even have modem lines connected. Sincerely, Karl Palsson [1] I had

excessive usb traffic with FT230x

newer. The usbmon traces seem to be a continual reporting of the 0x0160 shown in the ftdi_get_modem_status lines. Is this actually _meant_ to be happening? Can I turn it off? Any other suggestions? Sincerely, Karl Palsson

Re: Re: Re: excessive usb traffic with FT230x

of a transient flicker instead. Thanks kindly for the prompt and useful responses. Sincerely, Karl Palsson

Re: usb : serial : ch341 : set tty baud speed according to tty struct

Johan Hovold jo...@kernel.org wrote: Yes, there shouldn't be a need to store the baud rate in the driver (the tty layer will keep track of that), but you probably still want to store the state of the modem-control signals. Sounds right. The modem control signals I'm having a harder time

Re: Re: usb : serial : ch341 : set tty baud speed according to tty struct

can just be dropped out altogether. Sincerely, Karl Palsson

Re: Re: [possible fix] HL-340 USB don't work correctly (ch340 based usb-rs232 adapter)

Eddi De Pieri e...@depieri.net wrote: Hi Karl, I don't know but as documented by usbsnoop log the value written from kernel driver make my device to fail. Windows driver after some assumption write back the original value (0xc3) Ok, I'm still progressing on more of that init code,

Re: [possible fix] HL-340 USB don't work correctly (ch340 based usb-rs232 adapter)

unfortunately. Good news, I'm working on this again, bad news, I said that 6 months ago too :( My current work is at https://github.com/karlp/linux/tree/ch341-3.18.6 but note that this is only the initial cleanup, no fixes at this stage. Sincerely, Karl Palsson

Re: Re: ch341.c does not work with new ch34x devices

I'm seeing this as well, I've got some work in progress towards this, but not finding the time I'd hoped. CH340 devices work fine with the current linux driver, but CH341, very very very flaky, if at all.

Re: Re: [PATCH] USB: serial: add nt124 usb to serial driver

Johan Hovold jo...@kernel.org wrote: On Mon, Dec 08, 2014 at 05:24:17PM -0600, George McCollister wrote: + newline.bParityType = termios-c_cflag PARENB ? + (termios-c_cflag PARODD ? 1 : 2) + + (termios-c_cflag CMSPAR ? 2 : 0) : 0;

Re: [PATCH] cdc-acm: Drop the warning for unusual capabilities

COMM/ACM/0xff is likely MSFT RNDIS... NOT a modem! */ - /* Support Lego NXT using pbLua firmware */ - { USB_DEVICE(0x0694, 0xff00), - .driver_info = NOT_A_MODEM, - }, - Isn't this dropping the device too, not just the quirk? Sincerely, Karl Palsson -- To unsubscribe from

cdc-acm with incorrect bInterfaceSubClass

as working here: http://www.tablix.org/~avian/blog/archives/2013/05/gw_instek_afg_2005/ %DESCRIPTION1%=DriverInstall, USB\VID_2184PID_0011 %DESCRIPTION1%=DriverInstall, USB\VID_2184PID_001C Is there anything I can do to get this to turn up as an ACM device in linux? Sincerely, Karl Palsson

Re: cdc-acm with incorrect bInterfaceSubClass

On Mon, Oct 27, 2014 at 04:38:48PM +0100, Johan Hovold wrote: On Mon, Oct 27, 2014 at 02:52:59PM +, Karl Palsson wrote: Hi, I've got a GW Instek function generator (AFG-2225) that _appears_ like it should be a CDC-ACM device, but it seems to have a bug in it's descriptor

Re: [PATCH] USB: cdc-acm: add device id for GW Instek AFG-2225

On Mon, Oct 27, 2014 at 06:34:33PM +0100, Johan Hovold wrote: Add device-id entry for GW Instek AFG-2225, which has a byte swapped bInterfaceSubClass (0x20). Reported-by: Karl Palsson ka...@tweak.net.au Cc: stable sta...@vger.kernel.org Signed-off-by: Johan Hovold jo...@kernel.org

Re: [PATCH] usb/serial/ch341: Add parity support

and data bits. I have a CH340, which doesn't support variable stop/data bits, and another device with the chip labels scratched off, that could be either. This is going to take a while longer to redo unfortunately. Sincerely, Karl Palsson -- To unsubscribe from this list: send the line unsubscribe

Re: Driver CH341 USB Adapter Serial Port not Works in Linux

On Sun, Apr 13, 2014 at 08:51:56PM -0430, Kijam López wrote: The following code works for me correctly in Windows, but Linux does not work. I am using the same PC, both operating systems are installed native. I do not use virtual machine. I need to work on Linux. I have tried in different

patch: usb/serial/ch341: v2: Add parity support

Changes since v1: * Use the C_CMSPAR macros from 3.14 as requested by Johan Hovold v1 was here: http://comments.gmane.org/gmane.linux.usb.general/105940 Sincerely, Karl Palsson -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord

[PATCH] usb/serial/ch341: Add parity support

scratched off, and some Modbus/RTU devices that required various parity settings. Signed-off-by: Karl Palsson ka...@tweak.net.au --- drivers/usb/serial/ch341.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/usb/serial/ch341.c b/drivers/usb

Patch: usb/serial/ch341: Add parity support

I originally sent this to fr...@kingswood-consulting.co.uk who is listed as the maintainer for this driver, but I haven't heard a reply, so I'm posting to the list. This is my first patch for a driver, so I've tried to follow the existing style, but if there are any changes that should be made,

[PATCH] usb/serial/ch341: Add parity support

scratched off, and some Modbus/RTU devices that required various parity settings. Signed-off-by: Karl Palsson ka...@tweak.net.au --- drivers/usb/serial/ch341.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/usb/serial/ch341.c b/drivers/usb