Johan Hovold <> wrote:
> On Sun, Oct 16, 2016 at 05:09:24PM +0100, Aidan Thornton wrote:
> > On Mon, Oct 10, 2016 at 8:56 PM, Grigori Goronzy <> wrote:
> > > On 2016-10-08 23:07, Aidan Thornton wrote:
> > >>
> > >> On Fri, Oct 7, 2016 at 12:30 PM, Johan Hovold <> wrote:
> > >>>
> > >>> Why is this change needed? I see no write to this register in the
> > >>> vendor driver.
> > >>
> > >>
> > >> In principle, it might not be because the value written to register
> > >> 0x18 is probably overwritten by ch341_init_set_baudrate anyway. It's
> > >> there because it's in Grigori's original patch, it looks superficially
> > >> reasonable (corresponds to ENABLE_RX|ENABLE_TX|CS8, as opposed to the
> > >> rather implausible ENABLE_TX|PAR_EVEN|CS5), and given that some
> > >> hardware revisions are apparently a little temperamental I was
> > >> reluctant to remove it without fully understanding why it was added in
> > >> the first place. As the vendor driver does without it might make sense
> > >> to delete the write altogether, but it does do quite a few things
> > >> differently from this driver. Depends what Grigori says and the
> > >> results of actual testing.
> Ok, thanks for the explanation. I think we should try to get
> rid of anything apparently redundant eventually, moving towards
> how the vendor driver does things. It would also be good to
> replace more of the magic constants in there to make the code
> more self-describing.
> As long this is done in steps that can be (more easily)
> rolled-back in case it turns out we do actually break support
> for some device in the process.

Perhaps it needs to be repeated more, but the current driver is
so badly broken for so many devices that people simply don't use
them. This 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
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 soooo poor.

Karl Palsson

Attachment: signature.asc
Description: OpenPGP Digital Signature

Reply via email to