> I specifically asked for it. > > I can think of 2 reasons that userspace wants to know: > 1. Because the characteristics of the software emulation are unacceptable so > the application wants to terminate w/error rather than continue. But that could equally be true of hardware. In fact your software emulation is going to behave vastly better than many of the hardware ones. > 2. Because userspace will use different values for h/w vs. s/w. For example, > right now, the emulation will raise/lower RTS prematurely when tx ends if > the rts-after-send timer is 0. That's a bug then. It should be fixed as part of the merge or future patches - if they are not providing that emulation then they ought to do so and at least adjust the timing based on the baud rate so you don't have to spin polling the 16x50 uart to check the last bit fell out of the register. I'd have no problem with an API that was about asking what features are available : both hardware and software - but the software flag seems to make no sense at all. Software doesn't imply anything about quality or feature set. If there is something the emulation cannot support then there should be a flag indicating that feature is not supported, not a flag saying software (which means nothing - as it may be supported in future, or may differ by uart etc). It's also not "easy to drop". If it ever goes in we are stuck with a pointless impossible to correctly set flag for all eternity. Please explain the correct setting for this flag when a device driver uses hardware or software or a mix according to what the silicon is capable of and what values are requested ? How will an application use the flag meaningfully. Please explain what will happen if someone discovers a silicon bug and in a future 4.x release turns an implementation from hardware to software - will they have to lie about the flag to avoid breaking their application code - that strikes me as a bad thing. At the very least the above should be clearly explained in the documentation and patch covering notes - and if nobody can explain those then IMHO the flag is broken. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
