FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.3.0 2018-11-04T23:28:56Z 2018-11-04T23:28:56Z Matt Macy mmacy@FreeBSD.org 2018-11-04T23:28:56Z urn:sha1:07ef4418120bb9848c786af73548ff1a405b5596 Submitted by: Rajesh Kumar Differential Revision: https://reviews.freebsd.org/D17381 2018-03-29T02:50:57Z Eitan Adler eadler@FreeBSD.org 2018-03-29T02:50:57Z urn:sha1:4ab2e064d7950be84256d671a7ae93f87cc6aa36 This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re) 2018-03-14T03:19:51Z Eitan Adler eadler@FreeBSD.org 2018-03-14T03:19:51Z urn:sha1:be5d0b9566b13fdf8cabebb63334cbec12bfc409 These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg 2016-01-12T18:42:00Z Ian Lepore ian@FreeBSD.org 2016-01-12T18:42:00Z urn:sha1:fdfbb3f5b1b6199051e3421609c783b216cef6e5 option to invert the polarity in software. Also add an option to capture very narrow pulses by using the hardware's MSR delta-bit capability of latching line state changes. This effectively reverts the mistake I made in r286595 which was based on empirical measurements made on hardware using TTL-level signaling, in which the logic levels are inverted from RS-232. Thus, this re-syncs the polarity with the requirements of RFC 2783, which is writen in terms of RS-232 signaling. Narrow-pulse mode uses the ability of most ns8250 and similar chips to provide a delta indication in the modem status register. The hardware is able to notice and latch the change when the pulse width is shorter than interrupt latency, which results in the signal no longer being asserted by time the interrupt service code runs. When running in this mode we get notified only that "a pulse happened" so the driver synthesizes both an ASSERT and a CLEAR event (with the same timestamp for each). When the pulse width is about equal to the interrupt latency the driver may intermittantly see both edges of the pulse. To prevent generating spurious events, the driver implements a half-second lockout period after generating an event before it will generate another. Differential Revision: https://reviews.freebsd.org/D4477 2015-08-10T20:08:09Z Ian Lepore ian@FreeBSD.org 2015-08-10T20:08:09Z urn:sha1:196d3019a834a737ca8354fb37e801b999299d19 eliminating the need to build a custom kernel to use the CTS signal. The historical UART_PPS_ON_CTS kernel option is still honored, but now it can be overridden at runtime using a tunable to configure all uart devices (hw.uart.pps_mode) or specific devices (dev.uart.#.pps_mode). The per- device config is both a tunable and a writable sysctl. This syncs the PPS capabilities of uart(4) with the enhancements recently recently added to ucom(4) for capturing from USB serial devices. Relnotes: yes 2015-08-08T20:11:47Z Ian Lepore ian@FreeBSD.org 2015-08-08T20:11:47Z urn:sha1:b59236ceceb2864cedcb2a4c9b9db58f63be9eea time_pps_fetch() to be used in blocking mode. Also, don't init the pps api for system devices (consoles) that provide a custom attach routine. The device may actually be a keyboard or other non- tty device. If it wants to do pps processing (unlikely) it must handle everything for itself. (In reality, only a sun keyboard uses a custom attach routine, and it doesn't make a good pps device.) 2015-07-24T17:01:16Z Marius Strobl marius@FreeBSD.org 2015-07-24T17:01:16Z urn:sha1:86fb54003393c8c3c586df44fc31d7861e121ef3 uart_bus_attach() during its test that 20 iterations weren't sufficient for clearing all pending interrupts, assuming this means that hardware is broken and doesn't deassert interrupts. However, under pressure, 20 iterations also can be insufficient for clearing all pending interrupts, leading to a panic as intr_event_handle() tries to schedule an interrupt handler not registered. Solve this by introducing a flag that is set in test mode and otherwise restores pre-r253161 behavior of uart_intr(). The approach of additionally registering uart_intr() as handler as suggested in PR 194979 is not taken as that in turn would abuse special pccard and pccbb handling code of intr_event_handle(). [1] - Const'ify uart_driver_name. - Fix some minor style bugs. PR: 194979 [1] Reviewed by: marcel (earlier version) MFC after: 3 days 2015-04-11T17:16:23Z Andrew Turner andrew@FreeBSD.org 2015-04-11T17:16:23Z urn:sha1:405ada37fbdafaa6691a906f3630ba8d064e5f30 This is needed with the pl011 driver. Before this change it would default to a shift of 0, however the hardware places the registers at 4-byte addresses meaning the value should be 2. This patch fixes this for the pl011 when configured using the fdt. The other drivers have a default value of 0 to keep this a no-op. MFC after: 1 week 2013-02-02T11:38:26Z Andriy Gapon avg@FreeBSD.org 2013-02-02T11:38:26Z urn:sha1:5b23b1b9e72f192791a777b3419ed95538116c14 x86 buses Otherwise the uart hardware could be in such a state after the resume where IER is cleared and thus no interrupts are generated. This behavior is observed and tested with QEMU, so I am comitting this change to help with my debugging. There has been no feedback from users of serial ports on real hardware. MFC after: 20 days 2012-04-12T18:46:48Z Peter Grehan grehan@FreeBSD.org 2012-04-12T18:46:48Z urn:sha1:332cda07c00e3fd29889437c2de4d5dfcd10c6a3 used in polled-mode. The callout invokes uart_intr, which rearms the timeout. Implemented for bhyve, but generically useful for e.g. embedded bringup when the interrupt controller hasn't been setup, or if it's not deemed worthy to wire an interrupt line from a serial port. Submitted by: neel Reviewed by: marcel Obtained from: NetApp MFC after: 3 weeks