Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Sat, Jan 30, 2021 at 04:18:04PM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > our job is to make Linux work for everyone. > > But as your refusal to accept the purely additive (zero impact on > anything other than specific hw in question) patch adding support for > a new hardware device clearly indicates, your job is NOT to make Linux > work for everyone, but rather for a smaller subset of "everyone" > *other than* hardware designers who come to the maintainers in good > faith, asking to mainline support for new hardware they just made. Anything we take adds work to our overall effort to support that new feature added. And you are asking us to do that work for you, for free, for forever. Sorry, given that your attitude does not understand that this is a community and we need to work together, I don't think it's worth continuing here, sorry. If you change your mind in the future, you know how to contact us. greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
Greg K-H wrote: > our job is to make Linux work for everyone. But as your refusal to accept the purely additive (zero impact on anything other than specific hw in question) patch adding support for a new hardware device clearly indicates, your job is NOT to make Linux work for everyone, but rather for a smaller subset of "everyone" *other than* hardware designers who come to the maintainers in good faith, asking to mainline support for new hardware they just made. Johan Hovold wrote: > I couldn't find any such guarantee about the state of these pins when in > output mode in the document you refer to, but that's besides the point. The FTDI document in question shows when the pins in question transition between actively driving outputs and tristate, making it clear to hw engineers that the Hi-Z state must be handled gracefully, practically meaning that pull-up resistors to the I/O voltage rail need to the added. But as one can trivially confirm with an oscilloscope, the power-up transition is from tristate to driving HIGH, not low - the *only* time when the chip will drive low on these outputs is when the USB host explicitly commands it to, either by turning on DTR/RTS in UART mode or by switching to one of the non-UART modes in which these pins acquire different functions. > First, there are other serial devices than those from FTDI. The same principle applies to the initial power-up state of every other reasonable UART chip on the planet. Take the very original 8250 with good old +5V supply voltage - as you first apply power to the chip, the DTR and RTS outputs will be TTL high (corresponding to RS-232 inactive), and they *will not* drive low until and unless you write into the Modem Control Register to change their state. > Second, > these lines can be in any state when the OS boots (e.g. set by a > previous user or OS). If the user is specifically working with a special hardware device that does not tolerate DTR/RTS being randomly jerked around, it is that user's responsibility to ensure that there is NO "previous user or OS" anywhere in the picture. Right now the only active use case (active use case one meaning one with at least one live human actively campaigning for it in the present time) is my DUART28C, and in this active use case the USB-serial interface and the DTR/RTS-sensitive hardware behind this interface are inseparably integrated (a single PCB) into one special USB device. This special USB device does not exist at all to the host computer until the user plugs it in with the intent of operating on it - so there is *no* "previous user or OS" to talk about. > In fact, we already do provide such a way and perhaps that is what we > should use here. We can simply have the ftdi_sio driver not bind to > your control interface, which isn't a serial interface to begin with > anyway. > > Then you're free to use it in whatever way you prefer using libusb. Not acceptable: even though DTR and RTS lines from FT2232D Channel B are repurposed for a non-serial function, the main TxD & RxD lines on that FT2232D channel do form a standard serial interface, and it needs to work as such. Your proposal to use libusb for all serial communication on the secondary channel is unacceptable because it would require writing two versions of every userspace program that needs to talk to the second UART of the Calypso GSM chip: one special libusb-based version for use with DUART28C, and the other standard /dev/ttyXXX version for every other possible serial port to which the second UART of a Calypso GSM chip can be connected, of which there is a great multitude. One part that might not be obvious and probably needs clarification is that the second UART of the Calypso GSM chip (made by TI, not me) is a data-leads-only (TxD & RxD only) interface without any modem control or even hw flow control capability, hence whenever it is connected to any standard UART, that standard UART's modem control and flow control signals are left unconnected - thus DTR and RTS outputs go nowhere. "Standard" userspace software that talks to this UART interface (if one can use the word "standard" for software that is specifically written to speak the proprietary serial protocol of one particular chip vendor) thus does absolutely nothing regarding DTR and RTS - does not touch them in any way, beyond the kernel's automatic assertion on open and negation on close. My only innovation in the DUART28C adapter is to take these two otherwise unused outputs and repurpose them for a different useful function. My userspace programs take -Pdtr and -Prts options that cause these outputs to be pulsed; in the absence of these options (when the very same userspace program is used to talk to the very same TI chip going through a different hw path than my DUART28C), nothing special is done with DTR or RTS, and the kernel's automatic diddling of these lines poses no problem when they are unused and unconnected, as happens with every standard
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Fri, Dec 18, 2020 at 10:03:59AM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > We see devices that are "obviously" not the real vid/pid all the time in > > the wild. There's nothing "illegal" about another company using your > > vid/pid, look at all of the ones out there already that use the FTDI > > vendor id yet are "clones", same with pl2303 devices. > > But are those reusers of someone else's VID or PID coming to Linux > kernel maintainers with requests to modify ftdi_sio or pl2303 drivers > to work with their clones? Do you ever see LKML posts along the lines > of "Hi, I am so and so from such and such company, we are not FTDI but > we reuse FTDI's VID and PIDs, but our clone chip does not match the > original and we need to modify the ftdi_sio driver to work with our > poor man's clone chip" - do reusers of someone else's VID or PID come > here with such requests? Users of devices with cloned ids come to us asking why their devices do not work on Linux and how to fix them. Happens all the time, and as the job of a kernel is to enable hardware, we work to make this happen. The vendors who do this are no where to be found, of course, and telling people that the device they just purchased is "counterfit" doesn't really fall in our job description. We have all sorts of work-arounds in Linux drivers to support "fake" devices, our job is to make Linux work for everyone. Anyway, this is far off-topic for this thread, sorry, just letting you know why trying to rely on vid/pid is not the "final solution" people might think it is. I wish someone else would have weighed in on the different api options here, oh well, let me think about this over the next week or so... thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
Greg K-H wrote: > We see devices that are "obviously" not the real vid/pid all the time in > the wild. There's nothing "illegal" about another company using your > vid/pid, look at all of the ones out there already that use the FTDI > vendor id yet are "clones", same with pl2303 devices. But are those reusers of someone else's VID or PID coming to Linux kernel maintainers with requests to modify ftdi_sio or pl2303 drivers to work with their clones? Do you ever see LKML posts along the lines of "Hi, I am so and so from such and such company, we are not FTDI but we reuse FTDI's VID and PIDs, but our clone chip does not match the original and we need to modify the ftdi_sio driver to work with our poor man's clone chip" - do reusers of someone else's VID or PID come here with such requests? Let's apply this logic to the very specific example of USB VID:PID 0x0403:0x7152. Right now I am asking you, esteemed maintainers, to accept my patch to ftdi_sio adding support for this new custom ID along with the necessary quirk. If my patch were accepted and then someone else squats on this USB ID, how would it be a problem for anyone other than that squatter? Are you expecting that someone is going to file a bug report saying "I am using 0x0403:0x7152 for my own USB device, but there is a quirk for this ID in ftdi_sio, and I don't want that quirk for MY device using that ID" - is this what you are anticipating? If that scenario were to occur, how could it possibly be right to choose that hypothetical complainant's interest over mine if one can trivially check with FTDI and confirm that 0x0403:0x7152 is officially allocated to Falconia and not to the other contesting party? > We also have fuzzing devices that spoof vid/pid pairs in order to test > kernel code, as well as being used as malicious devices to hack systems > or do other "fun" things. And where is the harm? If my patch adding ftdi_sio support for 0x0403:0x7152 with the special quirk I am asking for were to be accepted, and then someone presents this USB ID to a target system as a form of hack or fuzzing test, where is the harm? If anything, such action would be a good thing, as it would exercise the quirk function and ensure that it doesn't crash the kernel or anything like that. Yes, the quirk flag will be set on that ttyUSB device - but if they are deliberately presenting a USB ID whose owner said "this ID means that this quirk is needed", then how is it a bad thing to apply the quirk when that ID is detected, fuzzing/hacking or not? > Blindly trusting these numbers are something > we can no longer do. Please clarify what you mean by "blindly trusting" in this very specific context. Suppose some company makes an entirely new USB- interfaced chip, they assign it a unique ID (obtained officially through proper channels, not taking squatting on else's), and they submit a brand new Linux driver for their brand new chip, a driver that naturally binds to that chip's new unique ID - are you going to reject that driver and keep the new chip forever unsupported by Linux because you are concerned that someone else will reuse that same USB ID for something completely different? How is my case any different? The only difference is that in my case the custom hw product is a board and not a chip - but how are board-level designs any less worthy of mainline Linux support than chip-level ones? Johan Hovold wrote: > My reasons for proposing the NORDY sysfs interface *and* termios flag > are as follows: The patch series presented so far provides the sysfs interface and the ftdi_sio ID-code-specific quirk for DUART28C (which would make me happy), but does not add any new termios flag. Are you planning to present a new patch series that also adds the new termios flag? > You cannot generally rely on the state of these lines before opening > the port at least once, I disagree. Manufacturers of USB-serial chips like FT232x/FT2232x *guarantee* (see FTDI's AN 184) that their DTR/RTS CMOS outputs *will not* drive low (they will either drive high or be tristated) until and unless an explicit command comes in on the USB control pipe to change those signals to the "on" state of CMOS low output. Therefore, hardware engineers have a right to demand from OS maintainers that OSes (who are middlemen between applications and hw) provide a way to NOT issue that particular USB control pipe command if it is not wanted by the application. > but for applications where this is possible > and where even toggling them once is undesirable s/undesirable/killer/, for the specific case of UART Channel B on FreeCalypso DUART28C, the custom board with the custom USB ID at the crux of my quest. > we *can* provide > some out-of-band mechanism to change the default state of the NORDY > flag (but we could also ignore this use case, keeping the status > quo). In the case of the parenthetical option, are you basically saying "screw you" to me and my users, refusing to mainline our
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Thu, Dec 10, 2020 at 10:59:41AM -0800, Mychaela Falconia wrote: > Maarten Brock wrote: > > Personally, I would prefer the VID:PID to enforce the quirk and an > > O_DIRECT (or other) flag used on open() as general backup plan. To > > me a sysfs solution seems illogical. > > A sysfs solution could work as a sort of poor man's substitute for a > VID:PID-driven quirk: instead of a driver quirk in the kernel, there > is a udev rule that detects a particular USB-serial device (perhaps > based on textual manuf/product strings as opposed to VID:PID) and sets > the needed sysfs flag. But then if we are talking about a special > USB device as opposed to generic serial as in RS-232 etc, then I argue > for a driver quirk: if the device has a custom VID:PID, a patch to the > driver is needed in any case just to recognize that custom ID, so why > not support the custom hw device properly by setting the quirk bit > right there and then? Seen in this light, the sysfs approach indeed > makes little sense. > > OTOH, if we are talking about RS-232 or similarly interfaced devices > which the user plugs into any random serial port (PC native, or a > random off-the-shelf USB-serial cable), then there is really nothing > that a udev rule can key onto, it is just a user plugging in some > serial device and then running custom userspace apps on it. In this > case asking the user to 'echo' something from the shell into /sys/blah > prior to running her userspace app seems illogical indeed, and asking > userspace app programmers to implement an equivalent sysfs write > internally is equally awkward. For this non-custom-USB-ID scenario I > thus agree that the O_DIRECT approach would be better - in this case > the userspace app programmer simply needs to add this one flag to > their open call, a trivial one line change. My reasons for proposing the NORDY sysfs interface *and* termios flag are as follows: - The change should be minimal, but still support non-standard use of the modem control signals. - The interface should be compatible with using standard tools (e.g. echo and cat). - We control all other aspects of this (e.g. HUPCL) using termios and should continue to do so. - We cannot change the default behaviour so this NORDY flag needs to be disabled by default (i.e. hence the negation). - You cannot generally rely on the state of these lines before opening the port at least once, but for applications where this is possible and where even toggling them once is undesirable we *can* provide some out-of-band mechanism to change the default state of the NORDY flag (but we could also ignore this use case, keeping the status quo). - This could be an interface to control just the initial state of this flag after probe() or it can be used in parallel with the termios interface. The latter is what is implemented here. - As a bonus, using sysfs for this allows this feature to be used also before NORDY support has been added to the c libraries. - A sysfs interface also integrates well with udev and allows custom hardware that depend on this to be setup up once at boot regardless of whether an RS-232 or USB-serial interface is used. Note that one of the BSDs recently added a termios flag with the same semantics as the proposed NORDY which seems to suggest that this is interface is indeed a natural one. Side note: Also the Windows API has a setting for the state of these lines *after* open (i.e. similar to a termios flag), and there are reports of Windows users not expecting the lines to be raised on first open (and behaviour changing between OS releases). For FTDI devices there appears to be some driver-specific out-of-band mechanism in the system properties for setting the default behaviour. Perhaps there's also some general mechanism, I have no idea, I've never used this API. But at least it doesn't seem to be as simple as Mychaela suggested earlier, that Win32 got this right, for example, by never raising the lines on open (by default). > Greg K-H wrote: > > > Companies/devices lie about vid:pid all the time, > > Wait, are you accusing *me* of lying? PID range 0x7150 through 0x7157 > out of FTDI's VID 0x0403 has been officially allocated by FTDI (please > feel free to confirm with FTDI, no need to take my word blindly) to > Falconia Partners LLC, which is *my* company - Falconia is my last > name. Therefore, any accusation of lying in connection with any > VID:PID in this range, including DUART28C VID:PID of 0x0403:0x7152, is > an accusation of lying against me personally, which I take very > seriously. Just chill, and then re-read what Greg wrote. > > wait until your > > specific vid:pid is repurposed for some other device and then what > > happens? :) > > O_DIRECT is an interesting hack, has anyone seen if it violates the > > posix rules for us to use it on a character device like this? > > According to open(2) Linux man page, O_DIRECT does not come from
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Fri, Dec 11, 2020 at 09:46:54AM +0100, Jiri Slaby wrote: > On 10. 12. 20, 19:59, Mychaela Falconia wrote: > > > O_DIRECT is an interesting hack, has anyone seen if it violates the > > > posix rules for us to use it on a character device like this? > > > > According to open(2) Linux man page, O_DIRECT does not come from POSIX > > at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus > > it seems like there aren't any POSIX rules to be violated here. > > > > If we go with O_DIRECT, what semantics are we going to implement? > > There are 3 possibilities that come to mind most readily: > > > > 1) O_DIRECT applies only to the open call in which this flag is set, > > and suppresses DTR/RTS assertion on that open. If someone needs to do > > multiple opens with DTR/RTS suppression being required every time, > > then they need to include O_DIRECT every time. > > > > 2) O_DIRECT applies not only immediately, but also sets a latched flag > > whereby all subsequent opens continue to suppress auto-assertion > > without requiring O_DIRECT every time. This approach by itself runs > > counter to the generic Unix way of doing things, but it may be OK if > > there is also some ioctl to explicitly set or clear the latched flag. > > > > 3) O_DIRECT applies only to the open call in which it is set, no > > built-in latching, but there is also some ioctl to control a flag > > enabling or disabling DTR/RTS auto-assertion on subsequent opens. > > 3) -- to allow standard tools to work on the device after the quirk is set > up once. I'm lost, what do you mean here? thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Thu, Dec 10, 2020 at 10:59:41AM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > Companies/devices lie about vid:pid all the time, > > Wait, are you accusing *me* of lying? PID range 0x7150 through 0x7157 > out of FTDI's VID 0x0403 has been officially allocated by FTDI (please > feel free to confirm with FTDI, no need to take my word blindly) to > Falconia Partners LLC, which is *my* company - Falconia is my last > name. Therefore, any accusation of lying in connection with any > VID:PID in this range, including DUART28C VID:PID of 0x0403:0x7152, is > an accusation of lying against me personally, which I take very > seriously. I am not saying you are using an "invalid id", or copying anything, see below: > > wait until your > > specific vid:pid is repurposed for some other device and then what > > happens? :) > > Let's break it down: > > 1) I do have an idea for a future hw product that could indeed reuse > DUART28C VID:PID - however, the reason for reusing the same USB ID is > that the potential product in question would have exactly the same > wiring inside and require the exact same handling from Linux, i.e., > suppress automatic DTR/RTS assertion on Channel B, but retain standard > behaviour on Channel A. > > 2) If I were to reuse the same USB ID for a different hw product that > should NOT receive the exact same quirk treatment, it would be 100% my > fault and I would have no right to run to OS maintainers complaining, > or even to sell such product, I would argue. > > 3) If some other party illegally squats on a PID out of FTDI's VID > range which FTDI officially allocated to me, and then comes to Linux > maintainers with a complaint however many years from now, whoever will > be the maintainer at that time will be able to check with FTDI, get an > official answer as to whom that PID rightfully belongs to, and that > will be the resolution. We see devices that are "obviously" not the real vid/pid all the time in the wild. There's nothing "illegal" about another company using your vid/pid, look at all of the ones out there already that use the FTDI vendor id yet are "clones", same with pl2303 devices. We also have fuzzing devices that spoof vid/pid pairs in order to test kernel code, as well as being used as malicious devices to hack systems or do other "fun" things. Blindly trusting these numbers are something we can no longer do. The point being, while it is nice to trigger off of these values, beware that it is not the only way that something like a userspace visable change should trigger off of because this is something that a user wants to have happen. This also makes it easier as it "should" work for all serial devices, and not be tied to specific hardware ids, requiring kernel updates for new devices that want to do this. hope this helps explain this a bit more. > > O_DIRECT is an interesting hack, has anyone seen if it violates the > > posix rules for us to use it on a character device like this? > > According to open(2) Linux man page, O_DIRECT does not come from POSIX > at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus > it seems like there aren't any POSIX rules to be violated here. Ah, for some reason I thought that newer POSIX releases finally defined this, as vendors wanted that written down so they could "rely" on it. Maybe not... thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On 2020-12-10 19:59, Mychaela Falconia wrote: Maarten Brock wrote: I agree. And an application not configuring the required handshakes, but still relying on them is an equal bug. This comment can be interpreted in at least two different ways. Are you referring to: 1) Mainstream existing applications that expect DTR and/or RTS to be asserted on open without doing any explicit TIOCMBIS, or 2) My fc-host-tools programs (fc-loadtool, fc-xram, rvinterf etc) that operate on the second UART of my DUART28C adapter, expect to NOT have auto-assertion of DTR/RTS on open, but rely on my custom USB ID and the ftdi_sio driver patch that goes with it to suppress this auto- assertion, without doing any explicit TIOCMBIC. If you are referring to 1, it is difficult to fault the authors of those applications, as they had every right to depend on the behaviour that had been codified in numerous official standards like POSIX. Or if you are referring to 2, what other choice do I have? With existing unpatched Linux kernels of every currently existing version, it is *impossible* to prevent DTR & RTS auto-assertion immediately on open of a tty device, thus applying a patch to the kernel (or at least to the ftdi_sio driver in my case) is the *only* way to make my hardware work with Linux. Doing a TIOCMBIC after open won't help, as it will be too late if the kernel already asserted DTR & RTS and thus caused an unwanted deep reset. I was referring to 1) And I still think that an application that *relies* on handshakes working should configure the handshakes, even if POSIX promises they should be set up. Any device with a classic old-fashioned RS-232 has probably already solved this in another way or is accepted as not working on Linux. If someone built such a device for their own personal enjoyment rather than for commercial sale, and needed to get it working with Linux, I suspect that person most likely applied a local patch to the kernel on their own system, likely implementing something similar to what is being discussed in this thread. A person might have done that, a company will probably just not support Linux or do a redesign with a different solution. Personally, I would prefer the VID:PID to enforce the quirk and an O_DIRECT (or other) flag used on open() as general backup plan. To me a sysfs solution seems illogical. A sysfs solution could work as a sort of poor man's substitute for a VID:PID-driven quirk: instead of a driver quirk in the kernel, there is a udev rule that detects a particular USB-serial device (perhaps based on textual manuf/product strings as opposed to VID:PID) and sets the needed sysfs flag. But then if we are talking about a special USB device as opposed to generic serial as in RS-232 etc, then I argue for a driver quirk: if the device has a custom VID:PID, a patch to the driver is needed in any case just to recognize that custom ID, so why not support the custom hw device properly by setting the quirk bit right there and then? Seen in this light, the sysfs approach indeed makes little sense. OTOH, if we are talking about RS-232 or similarly interfaced devices which the user plugs into any random serial port (PC native, or a random off-the-shelf USB-serial cable), then there is really nothing that a udev rule can key onto, it is just a user plugging in some serial device and then running custom userspace apps on it. In this case asking the user to 'echo' something from the shell into /sys/blah prior to running her userspace app seems illogical indeed, and asking userspace app programmers to implement an equivalent sysfs write internally is equally awkward. For this non-custom-USB-ID scenario I thus agree that the O_DIRECT approach would be better - in this case the userspace app programmer simply needs to add this one flag to their open call, a trivial one line change. Or use your option 3) mentioned below: open with O_DIRECT, use ioctl to set the sticky flag and close before starting the application. O_DIRECT is an interesting hack, has anyone seen if it violates the posix rules for us to use it on a character device like this? According to open(2) Linux man page, O_DIRECT does not come from POSIX at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus it seems like there aren't any POSIX rules to be violated here. If we go with O_DIRECT, what semantics are we going to implement? There are 3 possibilities that come to mind most readily: 1) O_DIRECT applies only to the open call in which this flag is set, and suppresses DTR/RTS assertion on that open. If someone needs to do multiple opens with DTR/RTS suppression being required every time, then they need to include O_DIRECT every time. 2) O_DIRECT applies not only immediately, but also sets a latched flag whereby all subsequent opens continue to suppress auto-assertion without requiring O_DIRECT every time. This approach by itself runs counter to the generic Unix way of doing things, but it may
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Thu, Dec 10, 2020 at 02:01:30PM +0100, Greg Kroah-Hartman wrote: > O_DIRECT is an interesting hack, has anyone seen if it violates the > posix rules for us to use it on a character device like this? Jiri only mentioned O_DIRECT as an example of a flag which we might be able to repurpose/abuse for this. O_DIRECT is linux-specific, not in POSIX, so we'd still end up with a Linux-specific interface if we were to take this route. Johan
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote: > Hello Mychaela, > > On 2020-12-09 23:49, Mychaela Falconia wrote: > > But the problem is that the current status quo is fundamentally broken > > for those hardware devices in which DTR and/or RTS have been repurposed > > for something other than modem and flow control. Right now whenever a > > "cold" (never previously opened) serial port is opened for the first > > time, that open action immediately and unstoppably asserts both DTR > > and RTS hardware outputs, without giving userspace any opportunity to > > say "no, please don't do it". Yes, this behaviour is codified in a > > bunch of standards that ultimately trace back to 1970s Original UNIX, > > but just because it is a standard does not make it right - this > > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a > > feature. > > I agree. And an application not configuring the required handshakes, but > still relying on them is an equal bug. Ehh, don't be silly. Relying on having Linux assert DTR/RTS on open is in no way a bug; it's the standard behaviour that we must continue to support unless explicitly overridden. Period. > > But if there exist some custom hw devices out there that are in the > > same predicament as my DUART28 adapter, but are different in that they > > are classic old-fashioned RS-232 rather than integrated USB-serial, > > with no place to assign a custom USB ID, *then* we need a non-USB-ID- > > dependent solution such as Johan's sysfs attribute or O_DIRECT. > > Any device with a classic old-fashioned RS-232 has probably already > solved this in another way or is accepted as not working on Linux. > > And then there is also the device tree (overlay?) through which a quirk > like this can be communicated to the kernel driver. Not sure if this > could help for a plug-and-play device like on USB. Not every system use devicetree and no, it doesn't help with hotpluggable buses either. Johan
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On 10. 12. 20, 19:59, Mychaela Falconia wrote: O_DIRECT is an interesting hack, has anyone seen if it violates the posix rules for us to use it on a character device like this? According to open(2) Linux man page, O_DIRECT does not come from POSIX at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus it seems like there aren't any POSIX rules to be violated here. If we go with O_DIRECT, what semantics are we going to implement? There are 3 possibilities that come to mind most readily: 1) O_DIRECT applies only to the open call in which this flag is set, and suppresses DTR/RTS assertion on that open. If someone needs to do multiple opens with DTR/RTS suppression being required every time, then they need to include O_DIRECT every time. 2) O_DIRECT applies not only immediately, but also sets a latched flag whereby all subsequent opens continue to suppress auto-assertion without requiring O_DIRECT every time. This approach by itself runs counter to the generic Unix way of doing things, but it may be OK if there is also some ioctl to explicitly set or clear the latched flag. 3) O_DIRECT applies only to the open call in which it is set, no built-in latching, but there is also some ioctl to control a flag enabling or disabling DTR/RTS auto-assertion on subsequent opens. 3) -- to allow standard tools to work on the device after the quirk is set up once. thanks, -- js
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
Greg K-H wrote: > Thanks for the long response, but I think you have to realize that > creating a new api for something that has been "how things work" since > the 1970's should not be taken lightly. No matter if it was a bug or > not, changing user-visable behavior is not a trivial thing. But I am NOT asking to change any user-visible behaviour on any existing hardware made by anyone other than me, instead I am merely asking to mainline a simple purely additive patch that adds support for my custom FTDI device with a custom USB ID, to spare my users the pain of applying that same patch locally on their own systems. As a secondary objective, I am also contributing my thoughts toward a generic solution for potential other affected devices that don't have the luxury of a custom PCB with a fully embedded USB-serial chip - but that one is more theoretical at the moment. > What we > come up with here has to stand the test of time of being able to be > supported properly for the next 40+ years. And how do we achieve this goal if the total number of people in the world who care in any way at all can be counted on one hand? Maarten Brock wrote: > I agree. And an application not configuring the required handshakes, but > still relying on them is an equal bug. This comment can be interpreted in at least two different ways. Are you referring to: 1) Mainstream existing applications that expect DTR and/or RTS to be asserted on open without doing any explicit TIOCMBIS, or 2) My fc-host-tools programs (fc-loadtool, fc-xram, rvinterf etc) that operate on the second UART of my DUART28C adapter, expect to NOT have auto-assertion of DTR/RTS on open, but rely on my custom USB ID and the ftdi_sio driver patch that goes with it to suppress this auto- assertion, without doing any explicit TIOCMBIC. If you are referring to 1, it is difficult to fault the authors of those applications, as they had every right to depend on the behaviour that had been codified in numerous official standards like POSIX. Or if you are referring to 2, what other choice do I have? With existing unpatched Linux kernels of every currently existing version, it is *impossible* to prevent DTR & RTS auto-assertion immediately on open of a tty device, thus applying a patch to the kernel (or at least to the ftdi_sio driver in my case) is the *only* way to make my hardware work with Linux. Doing a TIOCMBIC after open won't help, as it will be too late if the kernel already asserted DTR & RTS and thus caused an unwanted deep reset. > Any device with a classic old-fashioned RS-232 has probably already > solved this in another way or is accepted as not working on Linux. If someone built such a device for their own personal enjoyment rather than for commercial sale, and needed to get it working with Linux, I suspect that person most likely applied a local patch to the kernel on their own system, likely implementing something similar to what is being discussed in this thread. > And then there is also the device tree (overlay?) through which a quirk > like this can be communicated to the kernel driver. This method should indeed work for embedded boards that feature some kind of SoC where one or more native UARTs on that SoC need the quirk applied to them. But I don't have any such use cases, so let's defer this approach until and unless there is at least one person in the world who does. > Not sure if this > could help for a plug-and-play device like on USB. I don't see how this method can be useful at all for devices that connect to a standard (non-embedded) PC or laptop, whether USB or RS-232. > Personally, I would prefer the VID:PID to enforce the quirk and an > O_DIRECT (or other) flag used on open() as general backup plan. To > me a sysfs solution seems illogical. A sysfs solution could work as a sort of poor man's substitute for a VID:PID-driven quirk: instead of a driver quirk in the kernel, there is a udev rule that detects a particular USB-serial device (perhaps based on textual manuf/product strings as opposed to VID:PID) and sets the needed sysfs flag. But then if we are talking about a special USB device as opposed to generic serial as in RS-232 etc, then I argue for a driver quirk: if the device has a custom VID:PID, a patch to the driver is needed in any case just to recognize that custom ID, so why not support the custom hw device properly by setting the quirk bit right there and then? Seen in this light, the sysfs approach indeed makes little sense. OTOH, if we are talking about RS-232 or similarly interfaced devices which the user plugs into any random serial port (PC native, or a random off-the-shelf USB-serial cable), then there is really nothing that a udev rule can key onto, it is just a user plugging in some serial device and then running custom userspace apps on it. In this case asking the user to 'echo' something from the shell into /sys/blah prior to running her userspace app seems illogical indeed, and asking
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Thu, Dec 10, 2020 at 01:05:15PM +0100, Maarten Brock wrote: > On 2020-12-10 11:50, Greg Kroah-Hartman wrote: > > On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote: > > > Hello Mychaela, > > > > > > On 2020-12-09 23:49, Mychaela Falconia wrote: > > > > Greg K-H wrote: > > > > > > > > > I think we need more review for the rest of the series. This does > > > > > change the way serial ports work in a non-traditional way (i.e. using > > > > > sysfs instead of terminal settings). > > > > > > > > But the problem is that the current status quo is fundamentally broken > > > > for those hardware devices in which DTR and/or RTS have been repurposed > > > > for something other than modem and flow control. Right now whenever a > > > > "cold" (never previously opened) serial port is opened for the first > > > > time, that open action immediately and unstoppably asserts both DTR > > > > and RTS hardware outputs, without giving userspace any opportunity to > > > > say "no, please don't do it". Yes, this behaviour is codified in a > > > > bunch of standards that ultimately trace back to 1970s Original UNIX, > > > > but just because it is a standard does not make it right - this > > > > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a > > > > feature. > > > > > > I agree. And an application not configuring the required handshakes, > > > but > > > still relying on them is an equal bug. > > > > > > > But if there exist some custom hw devices out there that are in the > > > > same predicament as my DUART28 adapter, but are different in that they > > > > are classic old-fashioned RS-232 rather than integrated USB-serial, > > > > with no place to assign a custom USB ID, *then* we need a non-USB-ID- > > > > dependent solution such as Johan's sysfs attribute or O_DIRECT. > > > > > > Any device with a classic old-fashioned RS-232 has probably already > > > solved this in another way or is accepted as not working on Linux. > > > > > > And then there is also the device tree (overlay?) through which a > > > quirk > > > like this can be communicated to the kernel driver. Not sure if this > > > could help for a plug-and-play device like on USB. > > > > > > > > So I want to get a bunch of people > > > > > to agree that this is ok to do things this way now before taking this > > > > > new user-visible api. > > > > > > Personally, I would prefer the VID:PID to enforce the quirk and an > > > O_DIRECT (or other) flag used on open() as general backup plan. To > > > me a sysfs solution seems illogical. > > > > The "problem" of a vid:pid is that for usb-serial devices, that only > > describes the device that does the conversion itself, NOT the serial > > device the converter is plugged into that cares about these types of > > line-wiggling. > > > > Just like you would not want to classify all devices that met the PCI > > serial class signature for this type of thing either, there is nothing > > special about USB here other than it happens to be a common transport > > for these signals these days. > > > > thanks, > > > > greg k-h > > This is true for a generic USB-UART board or cable, but not for a > dedicated PCB where both the USB-UART chip and the special connection > are implemented and which has a dedicated VID:PID different from any > generic one. In this case the VID:PID describes the whole board. Companies/devices lie about vid:pid all the time, wait until your specific vid:pid is repurposed for some other device and then what happens? :) > If the line-wiggling requirement is created behind some sort of > connector (real RS-232 DB9/DB25 or CMOS pin header or whatever) > then the problem is the same as for an 8250 on any other bus. For > this situation I would prefer the O_DIRECT flag on open(). O_DIRECT is an interesting hack, has anyone seen if it violates the posix rules for us to use it on a character device like this? thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On 2020-12-10 11:50, Greg Kroah-Hartman wrote: On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote: Hello Mychaela, On 2020-12-09 23:49, Mychaela Falconia wrote: > Greg K-H wrote: > > > I think we need more review for the rest of the series. This does > > change the way serial ports work in a non-traditional way (i.e. using > > sysfs instead of terminal settings). > > But the problem is that the current status quo is fundamentally broken > for those hardware devices in which DTR and/or RTS have been repurposed > for something other than modem and flow control. Right now whenever a > "cold" (never previously opened) serial port is opened for the first > time, that open action immediately and unstoppably asserts both DTR > and RTS hardware outputs, without giving userspace any opportunity to > say "no, please don't do it". Yes, this behaviour is codified in a > bunch of standards that ultimately trace back to 1970s Original UNIX, > but just because it is a standard does not make it right - this > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a > feature. I agree. And an application not configuring the required handshakes, but still relying on them is an equal bug. > But if there exist some custom hw devices out there that are in the > same predicament as my DUART28 adapter, but are different in that they > are classic old-fashioned RS-232 rather than integrated USB-serial, > with no place to assign a custom USB ID, *then* we need a non-USB-ID- > dependent solution such as Johan's sysfs attribute or O_DIRECT. Any device with a classic old-fashioned RS-232 has probably already solved this in another way or is accepted as not working on Linux. And then there is also the device tree (overlay?) through which a quirk like this can be communicated to the kernel driver. Not sure if this could help for a plug-and-play device like on USB. > > So I want to get a bunch of people > > to agree that this is ok to do things this way now before taking this > > new user-visible api. Personally, I would prefer the VID:PID to enforce the quirk and an O_DIRECT (or other) flag used on open() as general backup plan. To me a sysfs solution seems illogical. The "problem" of a vid:pid is that for usb-serial devices, that only describes the device that does the conversion itself, NOT the serial device the converter is plugged into that cares about these types of line-wiggling. Just like you would not want to classify all devices that met the PCI serial class signature for this type of thing either, there is nothing special about USB here other than it happens to be a common transport for these signals these days. thanks, greg k-h This is true for a generic USB-UART board or cable, but not for a dedicated PCB where both the USB-UART chip and the special connection are implemented and which has a dedicated VID:PID different from any generic one. In this case the VID:PID describes the whole board. If the line-wiggling requirement is created behind some sort of connector (real RS-232 DB9/DB25 or CMOS pin header or whatever) then the problem is the same as for an 8250 on any other bus. For this situation I would prefer the O_DIRECT flag on open(). Maarten
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Thu, Dec 10, 2020 at 11:41:24AM +0100, Maarten Brock wrote: > Hello Mychaela, > > On 2020-12-09 23:49, Mychaela Falconia wrote: > > Greg K-H wrote: > > > > > I think we need more review for the rest of the series. This does > > > change the way serial ports work in a non-traditional way (i.e. using > > > sysfs instead of terminal settings). > > > > But the problem is that the current status quo is fundamentally broken > > for those hardware devices in which DTR and/or RTS have been repurposed > > for something other than modem and flow control. Right now whenever a > > "cold" (never previously opened) serial port is opened for the first > > time, that open action immediately and unstoppably asserts both DTR > > and RTS hardware outputs, without giving userspace any opportunity to > > say "no, please don't do it". Yes, this behaviour is codified in a > > bunch of standards that ultimately trace back to 1970s Original UNIX, > > but just because it is a standard does not make it right - this > > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a > > feature. > > I agree. And an application not configuring the required handshakes, but > still relying on them is an equal bug. > > > But if there exist some custom hw devices out there that are in the > > same predicament as my DUART28 adapter, but are different in that they > > are classic old-fashioned RS-232 rather than integrated USB-serial, > > with no place to assign a custom USB ID, *then* we need a non-USB-ID- > > dependent solution such as Johan's sysfs attribute or O_DIRECT. > > Any device with a classic old-fashioned RS-232 has probably already > solved this in another way or is accepted as not working on Linux. > > And then there is also the device tree (overlay?) through which a quirk > like this can be communicated to the kernel driver. Not sure if this > could help for a plug-and-play device like on USB. > > > > So I want to get a bunch of people > > > to agree that this is ok to do things this way now before taking this > > > new user-visible api. > > Personally, I would prefer the VID:PID to enforce the quirk and an > O_DIRECT (or other) flag used on open() as general backup plan. To > me a sysfs solution seems illogical. The "problem" of a vid:pid is that for usb-serial devices, that only describes the device that does the conversion itself, NOT the serial device the converter is plugged into that cares about these types of line-wiggling. Just like you would not want to classify all devices that met the PCI serial class signature for this type of thing either, there is nothing special about USB here other than it happens to be a common transport for these signals these days. thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
Hello Mychaela, On 2020-12-09 23:49, Mychaela Falconia wrote: Greg K-H wrote: I think we need more review for the rest of the series. This does change the way serial ports work in a non-traditional way (i.e. using sysfs instead of terminal settings). But the problem is that the current status quo is fundamentally broken for those hardware devices in which DTR and/or RTS have been repurposed for something other than modem and flow control. Right now whenever a "cold" (never previously opened) serial port is opened for the first time, that open action immediately and unstoppably asserts both DTR and RTS hardware outputs, without giving userspace any opportunity to say "no, please don't do it". Yes, this behaviour is codified in a bunch of standards that ultimately trace back to 1970s Original UNIX, but just because it is a standard does not make it right - this Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a feature. I agree. And an application not configuring the required handshakes, but still relying on them is an equal bug. But if there exist some custom hw devices out there that are in the same predicament as my DUART28 adapter, but are different in that they are classic old-fashioned RS-232 rather than integrated USB-serial, with no place to assign a custom USB ID, *then* we need a non-USB-ID- dependent solution such as Johan's sysfs attribute or O_DIRECT. Any device with a classic old-fashioned RS-232 has probably already solved this in another way or is accepted as not working on Linux. And then there is also the device tree (overlay?) through which a quirk like this can be communicated to the kernel driver. Not sure if this could help for a plug-and-play device like on USB. So I want to get a bunch of people to agree that this is ok to do things this way now before taking this new user-visible api. Personally, I would prefer the VID:PID to enforce the quirk and an O_DIRECT (or other) flag used on open() as general backup plan. To me a sysfs solution seems illogical. If the concern is with the new sysfs interface or the proposed O_DIRECT alternative, how about deferring those while allowing specific USB ID support to go in first? Right now there already exists at least one piece of hardware actively supported by its manufacturer (my gadget) that has a custom USB ID and requires the quirk - what is wrong with adding support for this existing specific hw? How about merging Johan's patch that defines the NORDY flag in tty_port, merging the ftdi_sio driver patch setting this flag for my custom USB ID, allowing other hardware engineers in the same boat to submit similar quirk patches for their affected custom hw with custom USB IDs, while deferring the sysfs patches until there is a more pressing need for quirky devices that have no custom USB IDs? Sincerely, Mychaela Again, I agree. Maarten
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Wed, Dec 09, 2020 at 02:49:45PM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > I think we need more review for the rest of the series. This does > > change the way serial ports work in a non-traditional way (i.e. using > > sysfs instead of terminal settings). > > But the problem is that the current status quo is fundamentally broken > for those hardware devices in which DTR and/or RTS have been repurposed > for something other than modem and flow control. Right now whenever a > "cold" (never previously opened) serial port is opened for the first > time, that open action immediately and unstoppably asserts both DTR > and RTS hardware outputs, without giving userspace any opportunity to > say "no, please don't do it". Yes, this behaviour is codified in a > bunch of standards that ultimately trace back to 1970s Original UNIX, > but just because it is a standard does not make it right - this > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a > feature. Thanks for the long response, but I think you have to realize that creating a new api for something that has been "how things work" since the 1970's should not be taken lightly. No matter if it was a bug or not, changing user-visable behavior is not a trivial thing. What we come up with here has to stand the test of time of being able to be supported properly for the next 40+ years. thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
Greg K-H wrote: > I think we need more review for the rest of the series. This does > change the way serial ports work in a non-traditional way (i.e. using > sysfs instead of terminal settings). But the problem is that the current status quo is fundamentally broken for those hardware devices in which DTR and/or RTS have been repurposed for something other than modem and flow control. Right now whenever a "cold" (never previously opened) serial port is opened for the first time, that open action immediately and unstoppably asserts both DTR and RTS hardware outputs, without giving userspace any opportunity to say "no, please don't do it". Yes, this behaviour is codified in a bunch of standards that ultimately trace back to 1970s Original UNIX, but just because it is a standard does not make it right - this Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a feature. All operating systems are fundamentally middlemen between applications and hardware. If custom application A is specifically written to work with custom hardware H, it is the operating system's job to allow A to operate on H without unreasonable interference, NOT to tell A and H that they should change their hw and/or app design to fit a given OS worldview. Furthermore, hardware engineers who design custom gadgets have a natural right to reduce hardware cost by employing designs that are simple and elegant in hw terms - they should NOT be forced to make hw designs more complicated, more expensive, or less convenient for end users in order to please an OS. To put it another way, OSes and OS maintainers need to see themselves as working for end users and their hardware and applications, not the other way around. Here is my situation: I needed a little hardware adapter that goes from USB to one UART with full modem and flow control signals (8-wire UART), one more UART with only data leads and no modem or flow control (2-wire UART), and two non-serial control signals that would allow a connected host computer to simulate PWON and RESET pushbutton presses. The simplest and most elegant hardware solution was to use an FT2232x chip from FTDI (either FT2232D or FT2232H, I chose the D version because I didn't need USB high speed), wire up one channel for the 8-wire UART, wire up the other channel for the 2-wire UART, and then repurpose the otherwise unused Channel B RTS & DTR outputs to drive PWON and RESET pushbutton signals via an open drain buffer IC. The entire hardware solution for driving my PWON and RESET signals consists of a single buffer IC that measures 1.00x1.45 mm - an epitome of hardware simplicity and elegance, I would argue. If my target OS was Windows, I wouldn't be having all these problems: under Windows when you open a "cold" serial port (USB-serial converter just plugged in, not previously opened) for the first time, that first-open action does NOT jerk DTR or RTS modem control signals, instead they are left alone - and the application program can then control and configure how they should function subsequently. But Linux is being a bad boy: when the serial port is opened, DTR and RTS are immediately asserted, and there is no way to prevent it other than by applying a local patch to the kernel on your system. I realize that changing the default first-open behaviour to leave DTR and RTS alone instead of asserting them would not be acceptable. There are lots of devices that require DTR and/or RTS to be asserted for serial communication to work, and because the standard (however poorly thought through) behaviour has always been to auto-assert these signals on open, most standard serial applications rely on this automatic assertion - almost no one does an explicit TIOCMBIS of DTR and RTS after open. Thinking as a hardware engineer, to me the most natural solution to this Linux problem is to use a custom USB ID upon which a driver quirk is then conditionalized. All major USB-serial chips feature either a built-in EEPROM or OTP configuration memory, or a provision for connecting a board-level EEPROM. One of the parameters set in this hardware config EEPROM is the USB VID:PID which the USB-serial chip will present itself as. Furthermore, most USB-serial chip vendors (at least FTDI and Silabs for sure) allow their customers (designers of custom hw containing their chips) to obtain a custom PID out of that chip vendor's USB VID, making it very very easy for custom USB-serial boards to have custom USB IDs. So I program the EEPROM on my custom DUART28 board with the custom USB ID which FTDI officially allocated to me (thus this ID code absolutely uniquely identifies my specific hardware and no other), and I prepare a patch for the ftdi_sio driver which I thought would be non-controversial: adding support for my new FT2232D-based device by adding its custom USB ID to the ID code table, along with a quirk that suppresses automatic assertion of DTR & RTS on open for the Channel B ttyUSB device. I thought my patch
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Wed, Dec 09, 2020 at 03:30:33PM +0100, Greg Kroah-Hartman wrote: > On Wed, Dec 02, 2020 at 12:39:35PM +0100, Johan Hovold wrote: > > This series adds a new NORDY port flag to suppress raising the > > modem-control lines on open to signal DTE readiness. > > > > This can be used to implement a NORDY termios control flag to complement > > HUPCL, which controls lowering of the modem-control lines on final > > close. > > > > Initially drivers can export the flag through sysfs, which also allows > > control over the lines on first open. Such an interface is implemented > > for serial core and USB serial. > > Also let me know if you prefer to hold this off for 5.12. The change is > > minimal, self-contained and low-risk, but it is a new interface and late > > in the release cycle as Andy pointed out. > > I took the first 2 patches now, that was easy :) > > I think we need more review for the rest of the series. This does > change the way serial ports work in a non-traditional way (i.e. using > sysfs instead of terminal settings). So I want to get a bunch of people > to agree that this is ok to do things this way now before taking this > new user-visible api. Sounds good, thanks. Johan
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Wed, Dec 02, 2020 at 12:39:35PM +0100, Johan Hovold wrote: > This series adds a new NORDY port flag to suppress raising the > modem-control lines on open to signal DTE readiness. > > This can be used to implement a NORDY termios control flag to complement > HUPCL, which controls lowering of the modem-control lines on final > close. > > Initially drivers can export the flag through sysfs, which also allows > control over the lines on first open. Such an interface is implemented > for serial core and USB serial. > > The motivation for this is to allow for applications where the DTR and > RTS lines are used for non-standard purposes (e.g. generating power-on > and reset pulses) to open the port without undesirable side effects. > > The final patches enables this flag by default for such a USB serial > device. > > Other examples include HAM-radio devices where DTR and RTS is used for > push-to-talk and continuous-wave control and various Arduino boards > which are reset on open unless a jumper is physically removed. > > Greg, are you ok we me taking this through my tree? I'm planning on some > follow ups to the ftdi driver and the tty/serial changes are fairly > self-contained. > > Also let me know if you prefer to hold this off for 5.12. The change is > minimal, self-contained and low-risk, but it is a new interface and late > in the release cycle as Andy pointed out. I took the first 2 patches now, that was easy :) I think we need more review for the rest of the series. This does change the way serial ports work in a non-traditional way (i.e. using sysfs instead of terminal settings). So I want to get a bunch of people to agree that this is ok to do things this way now before taking this new user-visible api. thanks, greg k-h
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On Wed, Dec 02, 2020 at 10:07:58AM -0800, Mychaela Falconia wrote: > On 12/2/20, Johan Hovold wrote: > > Also let me know if you prefer to hold this off for 5.12. The change is > > minimal, self-contained and low-risk, but it is a new interface and late > > in the release cycle as Andy pointed out. > > Hold off for 5.12? Did you perhaps mean 5.11? I understand how this > change may be too late for 5.10, but surely it can go into 5.11 merge > window, why hold off for 5.12? No, I meant 5.12, even if I still think this could go into 5.11. Generally new features should brew a bit in linux-next. It's mostly bots testing linux-next, and they wouldn't be able to catch anything beyond potential build issues as this feature is off by default anyway. So I don't think that needs to be an issue in this case. But we don't have deadlines and if, say, for one reason or another Greg doesn't have time to review this in the next couple of weeks, we'll just hold it off. Johan
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On 12/2/20, Johan Hovold wrote: > Also let me know if you prefer to hold this off for 5.12. The change is > minimal, self-contained and low-risk, but it is a new interface and late > in the release cycle as Andy pointed out. Hold off for 5.12? Did you perhaps mean 5.11? I understand how this change may be too late for 5.10, but surely it can go into 5.11 merge window, why hold off for 5.12? M~
