On Mon, Jan 09, 2017 at 02:51:59PM +0100, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 09:49:00PM +0100, Johan Hovold wrote:
> > On Tue, Dec 20, 2016 at 12:09:55PM -0800, Russell Senior wrote:
> > > On Tue, Dec 20, 2016 at 8:07 AM, Johan Hovold wrote:
> > >
> > > > Perhaps we should determine wh
On Tue, Dec 20, 2016 at 09:49:00PM +0100, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 12:09:55PM -0800, Russell Senior wrote:
> > 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, co
On Tue, Dec 20, 2016 at 12:09:55PM -0800, Russell Senior wrote:
> 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
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
On Tue, Dec 20, 2016 at 05:07:48PM +0100, Johan Hovold wrote:
> On Tue, Dec 20, 2016 at 04:38:19AM -0800, Russell Senior wrote:
> > > I'm not sure what device we're dealing with here, but it seems it would
> > > not be supported by the vendor (whose version of this driver also uses
> > > the init-c
On Tue, Dec 20, 2016 at 04:38:19AM -0800, Russell Senior wrote:
> > I'm not sure what device we're dealing with here, but it seems it would
> > not be supported by the vendor (whose version of this driver also uses
> > the init-command).
> >
> > Perhaps you could give the attached vendor driver a q
On Tue, Dec 20, 2016 at 07:31:55AM -0800, Russell Senior wrote:
> On Tue, Dec 20, 2016 at 1:13 AM, Johan Hovold wrote:
> > Perhaps you could give the attached vendor driver a quick spin just to
> > confirm that? It's a rebased version against usb-next.
>
> This is plain jane usb-next with your ve
On Tue, Dec 20, 2016 at 1:13 AM, Johan Hovold wrote:
> Perhaps you could give the attached vendor driver a quick spin just to
> confirm that? It's a rebased version against usb-next.
This is plain jane usb-next with your vendor patch, which I applied in
a local branch:
1-gfadd29d:
Dec 20 0
> I'm not sure what device we're dealing with here, but it seems it would
> not be supported by the vendor (whose version of this driver also uses
> the init-command).
>
> Perhaps you could give the attached vendor driver a quick spin just to
> confirm that? It's a rebased version against usb-next.
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:
> >>
> >> f341ee36198d ("dbg: ch3
On Mon, Dec 19, 2016 at 08:40:53AM -0800, Russell Senior wrote:
> On Mon, Dec 19, 2016 at 2:58 AM, Johan Hovold wrote:
> > On Sat, Dec 17, 2016 at 03:27:43AM -0800, Russell Senior wrote:
> >> All testing is with minicom.
> >
> > Thanks for this through report.
> >
> >> Starting with 00013-gc510871
>> 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")
>>
>> which provides dumps of the regist
On Mon, Dec 19, 2016 at 2:58 AM, Johan Hovold wrote:
> On Sat, Dec 17, 2016 at 03:27:43AM -0800, Russell Senior wrote:
>> All testing is with minicom.
>
> Thanks for this through report.
>
>> Starting with 00013-gc510871:
>>
>> In 8-bit mode, interoperates correctly with pl2303. Switching to
>>
On Sat, Dec 17, 2016 at 03:27:43AM -0800, Russell Senior wrote:
> All testing is with minicom.
Thanks for this through report.
> 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
All testing is with minicom.
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 get correct
text out both sides. Switching just th
On Fri, Dec 16, 2016 at 05:13:50PM +0100, Johan Hovold wrote:
> 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 branc
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
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?
Thanks
On Fri, Dec 16, 2016 at 6:46 AM, Johan Hovold wrote:
> On Fri, Dec 16, 2016 at 01:19:05PM +, Aidan Thornton wrote:
>> On Wed, Dec 14, 2016 at 3:28 PM, Johan Hovold wrote
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
> > certain devices.
> >
> >
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 the initial line
> se
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 more reaso
22 matches
Mail list logo
