18.8%
200 1984127 0.8%
500 2985075 40.3%
Measurements and working as a libre/open office document can be found at
https://jontio.github.io/linux_kernel_work/ch43x_tests.ods
Signed-off-by: Jonathan Olds
---
drivers/usb/serial/ch341.c | 46 ++++++
1 file chan
mit message with further details from
your other mail.
> Signed-off-by: jontio
You need to sign off with your full name. It should also match the From
line (author).
> ---
> drivers/usb/serial/ch341.c | 45 ++
> 1 file changed, 45 insertions(+)
>
&g
uot;[PATCH] USB: serial: ch341: fix wrong baud rate setting calculation"
> https://lore.kernel.org/linux-usb/20190608051309.4689-1-jon...@i4free.co.nz/
> ).
Good job, looks like you got most things right from the start, but I'll
comment on the patch directly.
> I've measured the
uot;[PATCH] USB: serial: ch341: fix wrong baud rate setting calculation"). The
> Get_maintainers.pl file didn't work for me I got...
>
> ../../../scripts/get_maintainer.pl
> 0001-USB-serial-ch341-fix-wrong-baud-rate-setting-calcula.patch
> ../../../scripts/get_maintainer.pl:
Hi Johan,
Thanks for the info. I followed
https://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patc
h-to-the-linux-kernel-and-responding-to-feedback/ and made a proposal patch
("[PATCH] USB: serial: ch341: fix wrong baud rate setting calculation"). The
Get_maintaine
Hi Johan,
Thanks for the info. I followed
https://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patc
h-to-the-linux-kernel-and-responding-to-feedback/ and made a proposal patch
("[PATCH] USB: serial: ch341: fix wrong baud rate setting calculation"
https://lore.kernel
t any baud rate and can produce a practically arbitrary large error
(for example a 40% error for 500) this patch does not address this
issue.
Signed-off-by: jontio
---
drivers/usb/serial/ch341.c | 45 ++
1 file changed, 45 insertions(+)
diff --git a/drivers/u
error handling
> doesn't work.
>
> Fixes: 2d5a9c72d0c4 ("USB: serial: ch341: fix control-message error handling")
> Signed-off-by: Dan Carpenter
Thanks for catching this.
Now applied with a stable tag as this could have security implications.
Johan
--
To unsubscribe
The "r" variable is an int and "bufsize" is an unsigned int so the
comparison is type promoted to unsigned. If usb_control_msg() returns a
negative that is treated as a high positive value and the error handling
doesn't work.
Fixes: 2d5a9c72d0c4 ("USB: serial: ch
On Sun, Apr 02, 2017 at 10:12:38AM -0700, Joe Perches wrote:
> On Sun, 2017-04-02 at 18:57 +0200, Leif Neland wrote:
> > There is a patch
> > https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch
> > which enables parity selection fo
On Sun, Apr 2, 2017 at 3:00 PM, Leif Neland wrote:
> There is a patch
>
> https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch
>
> which enables parity selection for the ch341 USB-RS485 adapter.
>
> From: Karl Palsson
> Date: T
There is a patch
https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch
which enables parity selection for the ch341 USB-RS485 adapter.
From: Karl Palsson
Date: Tue, 18 Mar 2014 23:33:27 +
This adapter is available for cheap on eBay.
The patch
On Sun, 2017-04-02 at 18:57 +0200, Leif Neland wrote:
> There is a patch
> https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch
> which enables parity selection for the ch341 USB-RS485 adapter.
>
> From: Karl Palsson Date: Tue, 18 Ma
> > Check for short transfers, and make sure to log any transfer errors.
> >
> > Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
> > Signed-off-by: Johan Hovold
> > ---
>
> As this can also lead to bits of uninitialised heap buff
> > > interrupts when the modem-status changes (e.g. remote end hangs up --
> > > > there should be debug messages)?
> > >
> > > Which version(s) would you like tested?
> >
> > You can use c51087107e88 ("USB: serial: ch341: rename modem-statu
.
>
> Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
> Signed-off-by: Johan Hovold
> ---
As this can also lead to bits of uninitialised heap buffers leaking to
user space via the modem-status interface, or to a remote device through
break control, I'll CC stable
be debug messages)?
> >
> > Which version(s) would you like tested?
>
> You can use c51087107e88 ("USB: serial: ch341: rename modem-status
> register").
As you noticed, I decided to revert to using direct register writes to
avoid having the modem-control lines be
Rename the shadow modem-status register currently named "line_status" to
the less confusing "msr".
Also rename the helper function used to parse the interrupt data.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 16
1 file changed, 8 insert
reopened.
Fixes: ba781bdf8662 ("USB: serial: ch341: add support for parity, frame
length, stop bits")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch3
) something which for example could cause problems
in setups where DTR is used to trigger a reset.
Fixes: 4e46c410e050 ("USB: serial: ch341: reinitialize chip on
reconfiguration")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 24 +---
1 file changed, 17
(reset-resume).
Fix this by dropping the redundant reconfiguration of the port at every
open, and only read the MSR after the interrupt URB has been submitted.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch
Rename the line-control-register variable in set_termios to "lcr" and
use u8 type to match the shadow register.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/serial
Rename the shadow modem-control register currently named "line_control"
to the less confusing "mcr".
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/seri
Fix reset-resume handling which failed to resubmit the read and
interrupt URBs, thereby leaving a port that was open before suspend in a
broken state until closed and reopened.
Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after
resume")
Fixes: 2bfd1c96a9fb ("USB
The modem-control signals are managed by the tty-layer during open and
should not be asserted prematurely when set_termios is called from
driver open.
Also make sure that the signals are asserted only when changing speed
from B0.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DT
The private baud_rate variable is used to configure the port at open and
reset-resume and must never be set to (and left at) zero or reset-resume
and all further open attempts will fail.
Fixes: aa91def41a7b ("USB: ch341: set tty baud speed according to tty
struct")
Fixes: 664d5df92e88
Clean up the control-transfer debug messages by dropping redundant
information and unnecessary casts.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
Make sure to stop the interrupt URB before returning on errors during
open.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletion
A short control transfer would currently fail to be detected, something
which could lead to stale buffer data being used as valid input.
Check for short transfers, and make sure to log any transfer errors.
Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
Signed-off
Some CH340 devices appear unable to change the initial LCR settings, so
set a sane 8N1 default during probe to enable basic support for such
devices.
Also drop a redundant LCR read during device initialisation.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 14 +-
1
DTR and RTS will be asserted by the tty-layer when the port is opened
and deasserted on close (if HUPCL is set). Make sure the initial state
is not-asserted before the port is first opened as well.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Cc: stable
Sig
This series fixes a number of problems with the ch341 driver, and adds
support for a class of CH340 devices which does not seem to support changing
the intial line settings (and does not support using the init vendor command to
do so either).
I noticed that using the init command to update the
, and if the
> > modem-control signals (DTR/RTS) are asserted at open? Do you get any
> > interrupts when the modem-status changes (e.g. remote end hangs up --
> > there should be debug messages)?
>
> Which version(s) would you like tested?
You can use c51087107e88 ("USB: se
On Tue, Dec 20, 2016 at 8:07 AM, Johan Hovold wrote:
> Perhaps we should determine what else is working or broken first,
> though.
>
> Russel, could you test if break-signalling works, and if the
> modem-control signals (DTR/RTS) are asserted at open? Do you get any
> interrupts when the modem-st
On Tue, Dec 20, 2016 at 7:52 AM, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 07:31:55AM -0800, Russell Senior wrote:
>> Not sure what the complaint about keys is about, I had not seen that
>> before.
>
> Related to module signing, not sure why you only see it with the vendor
> driver. Did you a
commit that tries to dump the registers differently
> > > (reading together with register 0x25):
> > >
> > > 3baa1eff4245 ("dbg: ch341: dump registers differently")
> >
> > 00019-g3baa1ef:
> >
> > Dec 20 04:30:50 willard kernel: usbcore: registered
could give the attached vendor driver a quick spin just to
> > confirm that? It's a rebased version against usb-next.
> >
> > I've also pushed a commit that tries to dump the registers differently
> > (reading together with register 0x25):
> >
> &g
in jane usb-next with your vendor patch, which I applied in
> a local branch:
>
> 1-gfadd29d:
>
> Dec 20 07:18:36 willard kernel: PKCS#7 signature not signed with a trusted key
> Dec 20 07:18:36 willard kernel: ch341: module verification failed:
> signature and/or required
9d:
Dec 20 07:18:36 willard kernel: PKCS#7 signature not signed with a trusted key
Dec 20 07:18:36 willard kernel: ch341: module verification failed:
signature and/or required key missing - tainting kernel
Dec 20 07:18:36 willard kernel: usbcore: registered new interface driver ch341
Dec 20 07:18
rebased version against usb-next.
>
> I've also pushed a commit that tries to dump the registers differently
> (reading together with register 0x25):
>
> 3baa1eff4245 ("dbg: ch341: dump registers differently")
00019-g3baa1ef:
Dec 20 04:30:50 willard kernel:
On Mon, Dec 19, 2016 at 02:12:05PM -0800, Russell Senior wrote:
> >> Apart from the two additional tests mentioned above, can you also
> >> provide a log from when connecting the device using the following commit
> >> that I just pushed to the ch341 branch:
> >
.
> >
> >> Starting with 00013-gc510871:
> >>
> >> In 8-bit mode, interoperates correctly with pl2303. Switching to
> >> 5-bit mode on both sides (I get unicode boxes of indeterminate
> >> values). Switching back to 8-bit mode on both sides, I g
>> Apart from the two additional tests mentioned above, can you also
>> provide a log from when connecting the device using the following commit
>> that I just pushed to the ch341 branch:
>>
>> f341ee36198d ("dbg: ch341: add register dumps to probe&
correctly with pl2303. Switching to
>> 5-bit mode on both sides (I get unicode boxes of indeterminate
>> values). Switching back to 8-bit mode on both sides, I get correct
>> text out both sides. Switching just the ch341 side back to 5-bit
>> mode, I get 0xff's out
f indeterminate
> values). Switching back to 8-bit mode on both sides, I get correct
> text out both sides. Switching just the ch341 side back to 5-bit
> mode, I get 0xff's out on the pl2303 side (still in 8-bit mode). This
> would seem to imply that byte-size changes are work
the ch341 side back to 5-bit
mode, I get 0xff's out on the pl2303 side (still in 8-bit mode). This
would seem to imply that byte-size changes are working on this
version. Changing baud rate also works.
00014-g79e475a:
dmesg shows on insert:
[ 1430.504116] usb 6-2: new full-speed USB d
. It's against my usb-next branch.
>
> I'll send you a couple of diagnostics patches as well shortly.
I ended up pushing a new branch, ch341 to my tree
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
which contains the full series as well as four debug patc
On Fri, Dec 16, 2016 at 08:04:18AM -0800, Russell Senior wrote:
> Sorry, I got distracted. I'm back now. Do you want me to test your
> 13 patch series? And what is that on top of?
Yes, please. It's against my usb-next branch.
I'll send you a couple of diagnostics patches as well shortly.
Than
, Johan Hovold wrote:
>> > The ch341 driver is based on reverse-engineering and contains some bits
>> > which appear to be redundant and some which appear incompatible which
>> > certain devices.
>> >
>> > Specifically, some CH340 devices seem unable to change
On Fri, Dec 16, 2016 at 01:19:05PM +, Aidan Thornton wrote:
> On Wed, Dec 14, 2016 at 3:28 PM, Johan Hovold wrote:
> > The ch341 driver is based on reverse-engineering and contains some bits
> > which appear to be redundant and some which appear incompatible which
>
On Fri, Dec 16, 2016 at 12:39:45PM +, Aidan Thornton wrote:
> On Thu, Dec 15, 2016 at 3:58 PM, Johan Hovold wrote:
> > On Wed, Dec 14, 2016 at 04:28:07PM +0100, Johan Hovold wrote:
> >> Some CH341 devices appear to require the use of the init vendor command
> >> to
On Wed, Dec 14, 2016 at 3:28 PM, Johan Hovold wrote:
> The ch341 driver is based on reverse-engineering and contains some bits
> which appear to be redundant and some which appear incompatible which
> certain devices.
>
> Specifically, some CH340 devices seem unable to change t
On Thu, Dec 15, 2016 at 3:58 PM, Johan Hovold wrote:
> On Wed, Dec 14, 2016 at 04:28:07PM +0100, Johan Hovold wrote:
>> Some CH341 devices appear to require the use of the init vendor command
>> to set the baud rate and line-control register. Specifically, while
>> using di
On Wed, Dec 14, 2016 at 04:28:07PM +0100, Johan Hovold wrote:
> Some CH341 devices appear to require the use of the init vendor command
> to set the baud rate and line-control register. Specifically, while
> using direct register updates for speed and LCR seem to update those
> settin
Make sure to stop the interrupt URB before returning on errors during
open.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletion
reopened.
Fixes: ba781bdf8662 ("USB: serial: ch341: add support for parity, frame
length, stop bits")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/
etting the divisors and lcr
> > directly for all CH340 devices, while using the new method for CH341
> > only (which requires it).
> >
> > Just want to make sure that keeping a common init sequence would still
> > work first.
> >
> > Note that I don't
Rename the shadow modem-control register currently named "line_control"
to the less confusing "mcr".
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/seri
A short control transfer would currently fail to be detected, something
which could lead to stale buffer data being used as valid input.
Check for short transfers, and make sure to log any transfer errors.
Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
Signed-off
Fix reset-resume handling which failed to resubmit the read and
interrupt URBs, thereby leaving a port that was open before suspend in a
broken state until closed and reopened.
Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after
resume")
Fixes: 2bfd1c96a9fb ("USB
Some CH341 devices appear to require the use of the init vendor command
to set the baud rate and line-control register. Specifically, while
using direct register updates for speed and LCR seem to update those
settings correctly, not using the init command causes received data to
be buffered until
Clean up the control-transfer debug messages by dropping redundant
information and unnecessary casts.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
(reset-resume).
Fix this by dropping the redundant reconfiguration of the port at every
open, and only read the MSR after the interrupt URB has been submitted.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch
The ch341 driver is based on reverse-engineering and contains some bits
which appear to be redundant and some which appear incompatible which
certain devices.
Specifically, some CH340 devices seem unable to change the initial line
settings, which have so far been set to 5N1. Let's use a
Rename the shadow modem-status register currently named "line_status" to
the less confusing "msr".
Also rename the helper function used to parse the interrupt data.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 16
1 file changed, 8 insert
DTR and RST will be asserted by the tty-layer when the port is opened
and deasserted on close (if HUPCL is set). Make sure the initial state
is not-asserted before the port is first opened as well.
Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
Cc: stable
Signed-off
The modem-control signals are managed by the tty-layer during open and
should not be asserted prematurely when set_termios is called from
driver open.
Also make sure that the signals are asserted only when changing speed
from B0.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DT
This series fixes a number of problems with the ch341 driver, and adds
support for a class of CH340 devices which does not seem to support
the new method of configuring the line settings (using the init vendor
command).
These patches have been verified against CH340G and CH341A, but I need
help
The private baud_rate variable is used to configure the port at open and
reset-resume, which means it must never be set to (and left at) zero or
reset-resume and all further open attempts will fail.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Cc: stable
Sig
t;> normal. I type an 'a' and I get and 'a' back. Likewise, I type an
>> >> >> 'A' and I get an 'A' back. I used a saved .minicom.dfl file to
>> >> >> configure the port.
>> >> >
>> >> > O
> >> >
> >> > Ok, so that seems to confirm the suspicion that changing settings after
> >> > the initial configuration is failing (even though the device does indeed
> >> > support 5-bit mode).
> >> >
> >> > Could you try to ve
On Mon, Dec 12, 2016 at 10:55:14AM -0500, Alan Stern wrote:
> On Mon, 12 Dec 2016, Johan Hovold wrote:
>
> > Ok, so that seems to confirm the suspicion that changing settings after
> > the initial configuration is failing (even though the device does indeed
> > support 5-bit mode).
>
> Perhaps is
'A' back. I used a saved .minicom.dfl file to
>> >> configure the port.
>> >
>> > Ok, so that seems to confirm the suspicion that changing settings after
>> > the initial configuration is failing (even though the device does indeed
>> > su
On Mon, 12 Dec 2016, Johan Hovold wrote:
> Ok, so that seems to confirm the suspicion that changing settings after
> the initial configuration is failing (even though the device does indeed
> support 5-bit mode).
Perhaps issuing a USB device reset before trying to change the settings
will help.
o confirm the suspicion that changing settings after
> > the initial configuration is failing (even though the device does indeed
> > support 5-bit mode).
> >
> > Could you try to verify if that applies to the baud rate as well? That
> > is, can you switch between say
try to verify if that applies to the baud rate as well? That
> is, can you switch between say 9600 and 115200 after opening the port
> and verify that against the pl2303?
>
> Still using usb-linus with the first LCR write removed.
I can change the baud rate on the ch341 and make it not wo
On Mon, Dec 12, 2016 at 07:09:34AM -0800, Russell Senior wrote:
> On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold wrote:
>
> > Ok, so maybe your device simply does not support changing the line
> > settings more than once. That is, the initial settings chosen are used
> > until re-connected. This w
On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold wrote:
> Ok, so maybe your device simply does not support changing the line
> settings more than once. That is, the initial settings chosen are used
> until re-connected. This would seem to be in accordance with a comment
> found in one of the out-of-
On Mon, Dec 12, 2016 at 04:36:54AM -0800, Russell Senior wrote:
> On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold wrote:
>
> > If you connect the ch340 you have in loopback mode, with the removed
> > initial LCR write that fixed the 5-bit behaviour, can you get that
> > behaviour back by setting 5-
On Mon, Dec 12, 2016 at 1:54 AM, Johan Hovold wrote:
> If you connect the ch340 you have in loopback mode, with the removed
> initial LCR write that fixed the 5-bit behaviour, can you get that
> behaviour back by setting 5-bit word size after opening the port? (This
> was what I was going for wit
On Mon, Dec 12, 2016 at 1:48 AM, Johan Hovold wrote:
> What exactly did you mean by "the baudrate change" above? If you revert
> to setting the divisors directly (rather than using SERIAL_INIT), we
> should be back to how things work in 4.9 (which you can get to work with
> the pl2303 by removing
patch in loopback seems to work with minicom
> regardless of wordsize. More so even than I would guess at 5N1: a ->
> a, A -> A. Trying to talk with a pl2303, 8N1 on both sides works.
> 7E1 works sending from ch341 to pl2303, but not pl2303 to ch341 (text
> is garbled on recept
On Fri, Dec 09, 2016 at 07:14:02AM -0800, Russell Senior wrote:
> >> Okay, I built your usb-linus
> >>
> >> 46490c347df406b3368680dd911620e52dc7bfa4
> >>
> >> with the line:
> >>
> >>r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
> >>
> >> commented out. More precisely:
> >
> >> Loopback wo
o do. The
>> usb-linus + previous patch in loopback seems to work with
>> minicom regardless of wordsize. More so even than I would guess
>> at 5N1: a -> a, A -> A. Trying to talk with a pl2303, 8N1 on
>> both sides works. 7E1 works sending from ch341 to pl2303, but
>>
g the word size is supposed to do. The
> usb-linus + previous patch in loopback seems to work with
> minicom regardless of wordsize. More so even than I would guess
> at 5N1: a -> a, A -> A. Trying to talk with a pl2303, 8N1 on
> both sides works. 7E1 works sending from ch341 to pl
han I would guess at 5N1: a ->
a, A -> A. Trying to talk with a pl2303, 8N1 on both sides works.
7E1 works sending from ch341 to pl2303, but not pl2303 to ch341 (text
is garbled on reception). 6N1 is garbled in both directions, but
differently.
Russell
--
To unsubscribe from this list: send the
>> Okay, I built your usb-linus
>>
>> 46490c347df406b3368680dd911620e52dc7bfa4
>>
>> with the line:
>>
>>r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
>>
>> commented out. More precisely:
>
>> Loopback works, and also interoperates with pl2303 (through a null
>> modem adapter).
>
> Interes
On Fri, Dec 09, 2016 at 10:21:32AM +, Aidan Thornton wrote:
> On Fri, Dec 9, 2016 at 3:26 AM, Russell Senior
> wrote:
> > On Thu, Dec 8, 2016 at 10:02 AM, Johan Hovold wrote:
> >> On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote:
> >>> > "Johan" == Johan Hovold writes:
> >
which previously did not work, but hopefully we can find a
combination that works for all (unless we can reliably determine the
device-type during probe).
Can you try the below patch on top of my usb-next branch?
I fear that your device does not support the new way of the setting the
divisor, but
ttps://lkml.kernel.org/r/CAKdnbx7GTH3K7eGtQ==wh=kb74ea_egpii0h8hxxokljnhh...@mail.gmail.com
>>
>> The weird part is I appear to have the same device, and it works fine
>> without that change.
>>
>> Could you try and just commenting out that register write in a mainline
&g
ge.
>
> Could you try and just commenting out that register write in a mainline
> kernel (or my usb-linus branch) to make sure the changes in -next did
> not cause the issues you still see when connected to a pl2303.
Okay, I built your usb-linus
46490c347df406b3368680dd911620e52dc7bfa4
w
re you using minicom on both ends with 115200 8N1 which appears to
work reliably, by the way?
> Johan> What is the lsusb -v output for you device? And what chip version
> Johan> is reported when connect the device if you enable dynamic
> Johan> debugging on usb-next (e.g. u
but it didn't interoperate
with my pl2303. Sending anything from the ch341 arrives at the pl2303
as 0x00, sending anything from the pl2303 arrives at the ch341 as 0xff.
Again, this is with GNU screen, started as: "screen /dev/ttyUSB${n}
115200" where ${n} is 0 or 1, depending on
not) but could you try
Johan> the below patch on top of usb-next as well? [...]
Your patch seems to have fixed it! Yay!
Johan> What is the lsusb -v output for you device? And what chip version
Johan> is reported when connect the device if you enable dynamic
Johan> debugging on usb-n
On Thu, Dec 08, 2016 at 10:37:28AM +0100, Johan Hovold wrote:
> [ +CC: Adain, Grigori, Karl ]
>
> On Wed, Dec 07, 2016 at 05:51:33PM -0800, Russell Senior wrote:
> > I still suspect shoddy hardware. It would be nice to hear someone else
> > with the ch341-based hardware to
e results). This was my first experience
> >> with or even awareness of ch341. I have much more experience with
> >> pl2303 and somewhat less with ftdi. With these ch341, when I type in
> >> an 'a' on one terminal, I get 0x01 out the other terminal. If I type
>>>>> "Johan" == Johan Hovold writes:
>> I attach the tty's with GNU screen (but I have also tried microcom
>> and minicom with the same results). This was my first experience
>> with or even awareness of ch341. I have much more experience with
&g
rial: USB Serial support registered for generic
> [822617.638736] usbcore: registered new interface driver ch341
> [822617.638755] usbserial: USB Serial support registered for ch341-uart
> [822617.638770] ch341 2-2.3:1.0: ch341-uart converter detected
> [822617.640272] usb 2-2.3: ch341-uar
0-Ser!
[822617.633618] usbcore: registered new interface driver usbserial
[822617.633638] usbcore: registered new interface driver usbserial_generic
[822617.633653] usbserial: USB Serial support registered for generic
[822617.638736] usbcore: registered new interface driver ch341
[822617.638755] usbs
are out of spec. This isn't a regression on the CH340G - they're exactly
>> the same before and after, so far as I can tell - but it might be on the
>> CH341 if baud rate setting worked better there before. Grigori might have
>> to take a look at that. Sorry for the incon
1 - 100 of 293 matches
Mail list logo
