On Thu, Sep 15, 2016 at 6:56 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Sep 15, 2016 at 12:03:48AM +0100, Aidan Thornton wrote: >> >> It looks like someone by the name of Grigori Goronzy (CCed) had a patch series >> or four attempting to do this that just never went anywhere like all the other >> attempts. Might be worth someone talking to him or looking at his patches. > > Do you have a pointer to those patches on the mailing list? Why were > they rejected? https://lkml.org/lkml/2016/4/15/849 Not entirely sure. I think mainly some quibble with an unrelated resume issue in the first patch and some objection to RTS/CTS and B0 handling for it being in separate patches, but but there's 13 patches in the series, four revisions of it, and probably other issues waiting to be discovered by the next fool who tries to resubmit them. > >> Seriously, this is... I was considering trying to get parity support merged so >> I don't have to keep patching it in, but it feels like a total waste of effort >> at this point after seeing all the other attempts. > > No reason you can't take those patches and fix them up and resend them, > right? Anything more complicated than parity support apparently runs into hardware quirks which unlike the author I simply don't have the hardware to test. Everything I've got uses the CH340G and all the people who do have the right hardware appear to have quite understandably given up. Would require buying more hardware from China, waiting for it to ship, spending a few hours with a logic analyzer, praying that this hasn't broken some other earlier chip revision, and likely all for nothing. Might consider it anyway but it makes more sense to keep on pointing people to the out-of-tree parity patch just like everyone else has been doing for the past two and a half years. Especially since most users will still need it for quite some time even if support does get merged. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html