On Fri, May 27, 2022 at 10:27:03PM +0000, Mychaela N. Falconia wrote: > Back in 1970s UNIX a poor design decision was made regarding serial port > handling; this bad design has been codified into standards (POSIX, SUS) > and persists into present-day Linux. Odd that you state it this way, as this IS the RS-232 standard requirement that was released in 1968, so codifying it into the POSIX standard and using it in Linux today was a good thing so that we can use Linux on hardware built for the standard. To ignore the public, accepted, standard is to become an operating system that does not follow the standard, which would not be a good thing at all. > In 2021 FreeBSD 13.0 became the > first Unix-style OS to fix the problem; the present patch series aims > to implement a similar solution in Linux. Again, this is not a "problem", it is a "let us use these pins for something that they were not designed to be used for" type of thing. You are wanting to ignore the well known and very common standard of the past 53 years because you wish to reuse a UART pin as a GPIO pin, which is not any sort of standardized thing at all. > The root of the problem is the POSIX/SUS-codified design decision to > always automatically assert both DTR and RTS modem control signals on > the initial open of a serial port, without giving userspace any ability > to say "no, please don't do it". Again, that is the standard, why wouldn't you want to do that? To not do that would be to break interoperability with millions of devices out there (remember modems?) > This design is flawed on a fundamental > philosophical level: an OS kernel needs to provide a mechanism for > applications to operate on hardware, rather than insert its own mind > in the middle. If a user wishes to open any kind of hardware device > and perform arbitrary operations on that device, the kernel needs to > allow this access unobstructed, provided that the user has the necessary > permissions. If the user is asking to merely open a hardware device, > but the kernel refuses to provide such "simple open" access without > mandatorily imposing some specific hardware action along with that > open, this behaviour needs to be considered a defect, a design bug. Again, this is not a design bug, but the requirement that the OS follow the 50+ year old documented and accepted standard for this hardware interface. This is designed properly. > Because the design bug is codified in POSIX, SUS etc, it cannot be > simply fixed - a change to default behaviour would violate standards > and break bazillion existing applications. Instead the only possible > solutions at this point in time have to take the form of creative > workarounds - and by necessity, such creative workarounds should NOT > be expected to be "pretty" or architecturally clean. The > architecturally-clean boat has sailed a few decades ago - in the > present time, non-pretty workarounds are required. Again, you are wanting a workaround for a limitation of your hardware design, not a limitation of the RS-232 standard. You are creating non-compliant hardware and wish to control it in a way the hardware was not originally intended to be controlled. And that's fine, but don't speak of it as if we somehow messed up 53 years ago and no one has noticed it since then. That's just condencending to all of us who have maintained and worked with this codebase and standard for these 50+ years. On a personal note, I've been working on UARTs and RS-232 since "only" 1992 on a paid basis, and I have never heard of anyone objecting to this portion of the RS-232 standard in a way to make it sound like it was designed incorrectly this way. But then again, I've only been doing this for 30 years now, maybe I'm too new at this :) > The solution implemented in FreeBSD relies on a feature of that OS > which does not exist in Linux: initial-state devices. Linux dropped those a long time ago for good reasons, let's not revisit that design decision again please. > There is also one other possibility: there exist some hardware devices > in which a USB-serial converter chip and the application circuit behind > that chip (which repurposes DTR & RTS for non-standard uses) are > integrated into a single monolithic device, with a custom USB VID:PID > identifying the hardware device as a whole. Because they are custom > ID codes not known at all to "naive" OS kernels, adding Linux support > for any such hw device will necessarily require adding knowledge of > that custom VID:PID to the appropriate USB-serial driver - and if it > is *known* that this paricular hardware device is wired in such a way > that requires the manual_rtsdtr flag to be set, then it makes the most > sense for the USB-serial driver to set the flag in the device-specific > quirk. The present patch series adds support for one such device. > > Mychaela N. Falconia (6): > tty: add port flag to suppress raising DTR & RTS on open > serial: core: add sysfs attribute to suppress raising DTR & RTS on > open > serial: core: fully suppress raising DTR & RTS on open if > manual_rtsdtr > USB: serial: add sysfs attribute to suppress raising DTR & RTS on open > USB: serial: ftdi_sio: pass port to quirk port_probe functions > USB: serial: ftdi_sio: add support for FreeCalypso DUART28C adapter >From what I recall with the original patch series, Johan is the author of these, not you. Rebasing and forwarding on is great, but please never drop original authorship of patches, that's just rude, and in some cases, ripe for legal worries. Can you fix that all up, tone down the "this is all wrong" verbage, and properly resend the series as a joined patch series (your emails are not threaded properly at all and our tools can not find them correct, just use 'git send-email' and that would solve it.) and then after the merge window, I'll reconsider this series. Also please document what has changed since Johan's original submission to now, and why it should now be accepted when it was rejected then. thanks, greg k-h
