On Mon, Oct 10, 2016 at 8:56 PM, Grigori Goronzy <g...@chown.ath.cx> wrote:
> On 2016-10-08 23:07, Aidan Thornton wrote:
>> On Fri, Oct 7, 2016 at 12:30 PM, Johan Hovold <jo...@kernel.org> 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.
> Yes, I think I introduced it for consistency. The whole init sequence is a
> bit strange and doesn't make too much sense, but I tried to avoid modifying
> it because I don't know how the different hardware revisions react to that.
> In theory it shouldn't make a difference as the chip is reinitialized later
> on, though.
> By the way, I tested the series against my CH341A board and it works just
> fine, as expected.
> Best regards
> Grigori

Ah, OK. Thanks for the help and sorry for the late reply, this got
buried under a pile of other e-mails in my inbox and it took me a
while to see it. Thoughts on omitting the write to 0x2518 altogether
then? Doing so doesn't seem to cause any problems on the CH340G I'm
testing on, but obviously I can't guarantee this will always be the
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

Reply via email to