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
how 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
that _is_broken_ and they're all in limbo because "compatibility
with unknown magic number XYZ" that cant' be explained anyway.
Is there any chance of any improvements to this driver ever
landing? The requirements have been so high, when the existing
was s poor.
Sincerely,
Karl Palsson
signature.asc
Description: OpenPGP Digital Signature
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 CH340G and CH341A. T
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
> ---
> drivers/usb/serial/ch341.c | 19 +
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
> Signed-off-by: Grigor
-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
s 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 easy
right
-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 that this is a requirement
-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
> logic to configure the GPIO for
last work is
here https://github.com/karlp/linux/tree/ch341-3.18.6 and included some work
on reading out the baud rate. It also supports the reopening problems but it's
not ready for submission.
I can test out some fixes, but it's simply not a priority for me rig
aving one of the applications that uses the serial
port to kick of a transient flicker instead.
Thanks kindly for the prompt and useful responses.
Sincerely,
Karl Palsson
ssarily be
> forwarded every millisecond either anymore.
>
Ok, 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&#
nything in the ftdio_sio driver other than new VID/PIDs
since 3.18, so I haven't tried anything 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
Johan Hovold 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
setting up good
/ch341-3.18.6
By implementing proper reading of settings from the device, a lot of the
private copies can just be dropped out altogether.
Sincerely,
Karl Palsson
Eddi De Pieri 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, but what I
devices that needs
> ch341.ko to check that it works properly even if you comment out
> before sending a patch back to the ML.
>
It needs a lot more than just commenting out that line 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
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.
Johan Hovold 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;
>
>
> /* NOTE: non-Nokia 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
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
> Cc: stable
> Signed-off-by: Johan Hovold
> ---
>
> Care to give this pat
On Mon, Oct 27, 2014 at 04:38:48PM +0100, Johan Hovold wrote:
> On Mon, Oct 27, 2014 at 02:52:59PM +0000, 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
r as they're concerned, the new and
old devices are the same. (Old device listed as working here:
http://www.tablix.org/~avian/blog/archives/2013/05/gw_instek_afg_2005/
%DESCRIPTION1%=DriverInstall, USB\VID_2184&PID_0011
%DESCRIPTION1%=DriverInstall, USB\VID_2184&PID_001C
Is ther
oth types keep working?
This is also why I don't want to go too far with trying to test stop bits 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 linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
scratched off, and
some Modbus/RTU devices that required various parity settings.
Signed-off-by: Karl Palsson
---
drivers/usb/serial/ch341.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index
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
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
scratched off, and
some Modbus/RTU devices that required various parity settings.
Signed-off-by: Karl Palsson
---
drivers/usb/serial/ch341.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index
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, pl
29 matches
Mail list logo
