On Mon, Dec 27, 2010 at 11:40:47PM -0700, Pete Zaitcev wrote:
> On Mon, 27 Dec 2010 20:04:51 -0800 (PST)
> Tsozik <tsozik@xxxxxxxxx> wrote:
>
> > So I ran geiger counter against /dev/ttyS0 device for 20 minutes and
> > acquired 20 measurements. Then I compared last average with last 20
> > minute measurement average acquired via mct_u232 on the laptop placed
> > nearby. The error was ~4% (rounded up).
>
> Great, I'm ready to ack.
>
> There's just one thing that is bugging me... I think it would be best
> if Alan Cox or Greg Kroah commented on it. The edgeport does the
> following, which we copied:
>
>
> schedule();
> ........
> if (cnow.rng == cprev.rng && cnow.dsr == cprev.dsr &&
> cnow.dcd == cprev.dcd && cnow.cts == cprev.cts)
> return -EIO; /* no change => error */
> if (((arg & TIOCM_RNG) && (cnow.rng != cprev.rng)) ||
> ((arg & TIOCM_DSR) && (cnow.dsr != cprev.dsr)) ||
> ((arg & TIOCM_CD) && (cnow.dcd != cprev.dcd)) ||
> ((arg & TIOCM_CTS) && (cnow.cts != cprev.cts))) {
> return 0;
> }
>
> So, if there was a status report, but no change to bits, the ioctl
> TIOCMIWAIT would return with -EIO. In serial_core.c, that serves
> conventional non-USB UARTs, nothing like this occurs. I am not quite
> sure what the point of doing this -EIO check is.
Odd, I don't really remember where I copied that logic from, that was a
long time ago.
> Oh and BTW, I'm wondering what is going to happen if the device is
> disconnected while an application is blocked waiting for the status
> change. The patch is not particularly bad here, it just copies
> an existing code from elsewhere.
It should handle the disconnect, if not, we should fix it.
thanks,
greg k-h
--
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
