Previously the polarity was for TTL levels, which are the reverse of RS-232.
Also add handling of the UART_PPS_INVERT_PULSE option bit in the sysctl
value, the same as was recently added to uart(4), so that people using TTL
level connections can request a logical inverting of the signal.
Use the named constants from the new dev/uart/uart_ppstypes.h for the pps
capture modes and option bits.
tables. Some drivers needed some slight re-arrangement of declarations
to accommodate this. Change the USB pnp tables slightly to allow
better compatibility with the system by moving linux driver info from
start of each entry to the end. All other PNP tables in the system
have the per-device flags and such at the end of the elements rather
that at the beginning.
Differential Review: https://reviews.freebsd.org/D3458
The ftdi chip itself has a "get bitmode" command that doesn't actually
return the current bitmode, just a snapshot of the gpio lines. The chip
apparently has no way to provide the current bitmode.
This implements the functionality at the driver level. The driver starts
out assuming the chip is in UART mode (which it will be, coming out of
reset) and keeps track of every successful set-bitmode operation so that
it can always return the current mode with UFTDIIOC_GET_BITMODE.
interface without breaking ABI or API compatibility with existing drivers.
The existing data structures used to communicate between the kernel and
driver portions of PPS processing contain no spare/padding fields and no
flags field or other straightforward mechanism for communicating changes
in the structures or behaviors of the code. This makes it difficult to
MFC new features added to the PPS facility. ABI compatibility is
important; out-of-tree drivers in module form are known to exist. (Note
that the existing api_version field in the pps_params structure must
contain the value mandated by RFC 2783 and any RFCs that come along after.)
These changes introduce a pair of abi-version fields which are filled in
by the driver and the kernel respectively to indicate the interface
version. The driver sets its version field before calling the new
pps_init_abi() function. That lets the kernel know how much of the
pps_state structure is understood by the driver and it can avoid using
newer fields at the end of the structure that it knows about if the driver
is a lower version. The kernel fills in its version field during the init
call, letting the driver know what features and data the kernel supports.
To implement the new version information in a way that is backwards
compatible with code from before these changes, the high bit of the
lightly-used 'kcmode' field is repurposed as a flag bit that indicates the
driver is aware of the abi versioning scheme. Basically if this bit is
clear that indicates a "version 0" driver and if it is set the driver_abi
field indicates the version.
These changes also move the recently-added 'mtx' field of pps_state from
the middle to the end of the structure, and make the kernel code that uses
this field conditional on the driver being abi version 1 or higher. It
changes the only driver currently supplying the mtx field, usb_serial, to
use pps_init_abi().
Reviewed by: hselasky@
Huawei. It might appear as if the firmware is allocating memory blocks
according to the USB transfer size and if there is initially a lot of
data, like at the answering machine prompt, it simply dies without any
apparent reason. The simple workaround for this is to force a zero
length packet at hardware level after every 512 bytes of data. This
will force the other side to use smaller memory blocks aswell.
MFC after: 1 week
rules prevent the USB serial module to be unloaded before any client
modules. This patch ensures that the "ucom_mtx" mutex is destroyed
last when doing a system uninit in a monotolith build aswell.
MFC after: 3 days
These changes prevent sysctl(8) from returning proper output,
such as:
1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.
Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
a jtag debugging product, which was used on early Beaglebone boards (later
boards used a standard FTDI 2232C product ID). Change the name accordingly,
and also add an entry for XDS100V3, the latest version of that product
which has its own new product ID number.
Device type and revision is now determined from the bcdDevice field and
doesn't need to be in the table at all. The feature that skips creation
of /dev/ttyU* entries for jtag and gpio interfaces is enhanced:
- The feature is now optional, but enabled by default. A tunable and
sysctl are available to control it: hw.usb.uftdi.skip_jtag_interfaces.
- We no longer assume interface #0 is the only jtag interface. Up to
eight interfaces per chip can be flagged as jtag. (Current ftdi chips
support a max of 4 interfaces; this leaves room for growth.)
- Some manufacturers don't change the product ID or use the same ID for
different devices intended for both serial-comms and jtag/gpio use.
Often while the product ID is the same, the product name string is
different, so it's now possible to search for the product name in a
table of strings and get the set of non-tty interfaces from that table.
- Add a comment about FTDI and ZLPs.
- Correctly check odditiy of baud rate divisor.
- Correct IOCTL handling for "error" and "event" char.
MFC after: 1 weeks
other modes supported by the FTDI serial adapter chips.
In addition to adding the new ioctls, this change removes all the code
that reset the chip at attach and open/close time, and also the code
that turned on RTS/CTS flow control on open without any permission to do
so (that was just always a bug in the driver).
When FTDI chips are configured as GPIO or MPSSE or other special-purpose
uses by an attached serial eeprom, the chip will power on with certain
pins driven or floating, and it's important that the driver not do
anything to the chip to perturb that unless it receives a specific
command to do so. When used for "plain old serial comms" the chip
powers on into the right mode and never needs to be reset while it's
running to operate properly, so this change is transparent to most users.
default wMaxPacketSize (64 or 512 bytes). This actually helps older FTDI
devices (which were USB 1/full speed) more than the new H-series high
speed, but even for the new chips it helps cut the number of interrupts
when doing very high speed (3-12mbaud).
Recent FDTI chips have the ability to operate at up to 12mbps. The newer
chips with faster clocks have the same usb vendor/product IDs as the older
chips; the bcdDevice field must be used to detect the newer versions. This
change includes a new function to do that instead of using just the IDs from
the vendor/product table.
The code to choose the baud clock divisor is completely rewritten. In
addition to supporting the new higher clock rates, the rewrite fixes a
longstanding bug in the old code which put the high bits of the fractional
part of the divisor into the wrong place in the wIndex field. That bug
was mostly harmless -- it accidentally didn't affect standard baud rates
and would only show up when using relatively fast non-standard rates.
The NetBSD Foundation states "Third parties are encouraged to change the
license on any files which have a 4-clause license contributed to the
NetBSD Foundation to a 2-clause license."
This change removes clauses 3 and 4 from copyright / license blocks that
list The NetBSD Foundation as the only copyright holder.
Sponsored by: The FreeBSD Foundation
