Re: usbserial / ftdi_sio (+ others) bug?

[Johan Hovold <johan@kernel.org>]

On Tue, Nov 04, 2014 at 08:29:13PM +0200, Janne Huttunen wrote:
> On Tue, 4 Nov 2014 09:14:49 +0100
> Johan Hovold <johan@kernel.org> wrote:
> > > 2. The chip responds with single correct character followed by a few
> > >    hundred or so replies containing only the overrun status (no
> > > data) which are then converted to a bunch of binary zeroes by the
> > > ldisc because of the bug I mentioned earlier. After that the chip
> > > starts responding with proper data again and works until closed.
> > 
> > Note that the only "bug" is that the application cannot disable the
> > overrun reporting, but why would you want that?
> 
> The merits of doing so may be debatable, but if using the quotes
> around "bug" is supposed to indicate that it isn't one, I have
> to respectfully disagree. I know it is not the most important
> thing in the world and without the hardware fault I probably
> would not have seen it at all, but I would still call it a bug.

And so have I. It is a bug, but it's not what causing your problems
here. In fact, I would argue that you do not even want to disable
overrun reporting. That was my point.

> > What's on the other side of the FTDI chip?
> 
> Some kind of an optical receiver circuit (the link is optically
> isolated). On the other side of that is then the device that sends
> periodical data packets (a couple of times per second 17 bytes
> each) to the computer. The computer doesn't send anything i.e.
> the tx functionality of the chip is not used at all.

What baudrates? Have you verified the RS232 signals?

> > It still sounds like your hardware is broken, but at least you
> > seem to have found a work-around.
> 
> Like I said, the hw is the real culprit here, there's no doubt
> about it. But I also doubt that it's just the individual chip
> in my device that has this issue. The device is practically
> brand new and while that is no guarantee that there won't be any
> faults, I find it much more likely that what I am seeing here is
> a quirk of the implementation and there are lots of these chips
> with the same issue out there.

Your device behaving this way is the first one I hear of. 

> The real questions that remain are then; 1. is the chip real or
> counterfeit and how am I supposed to know it,

No idea.

I have three FT232R plugged in as we speak and they have the same
descriptors as yours (bcdDevice etc). Haven't had any issues with them.

> 2. how much the driver can or even should try to accommodate the
> quirks of the hw, and

Without knowing for sure that this is an issue with a class of devices,
there's not much we can do.

> 3. does the answer to #2 depend on the answer to #1.

Yes.

> > Perhaps you can report it to the logging-device (?) manufacturer
> > or FTDI.
> 
> Sure, if I can find someone that cares, which is doubtful.

If the chip is sold as part of the logging device, I would hope the
manufacturer would.

Johan