Merge head from 7/28

Sync to HEAD@r269943.

Remove unused defines.
Fix some device_printf's that were missing '\n' at the end or had
speling errors.

PR: 145319
Submitted by: rozhuk.im gmail.com

Pull in r267961 and r267973 again. Fix for issues reported will follow.

Revert r267961, r267973:

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

Revert r267961, r267973:

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

show more ...

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statica

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
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

show more ...

MFC @ r266724

An SVM update will follow this.

IFC @266473

Merge head

The FTDI product ID we've been calling BEAGLEBONE is actually TI XDS100V2,
a jtag debugging product, which was used on early Beaglebone boards (later
boards used a standard FTDI 2232C product ID). C

The FTDI product ID we've been calling BEAGLEBONE is actually TI XDS100V2,
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.

show more ...

Remove device type from the uftdi_devs table, enhance the jtag-skip feature.

Device type and revision is now determined from the bcdDevice field and
doesn't need to be in the table at all. The feat

Remove device type from the uftdi_devs table, enhance the jtag-skip feature.

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.

show more ...

IFC @264767

Oops, revert r264801.

Add a missing break.

- Get transmit loop more in line with the other serial drivers.
- Add a comment about FTDI and ZLPs.
- Correctly check odditiy of baud rate divisor.
- Correct IOCTL handling for "error" and "event" c

- Get transmit loop more in line with the other serial drivers.
- 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

show more ...

Add ioctl(2) calls to uftdi(4) to access bitbang, MPSSE, CPU_FIFO, and
other modes supported by the FTDI serial adapter chips.

In addition to adding the new ioctls, this change removes all the code

Add ioctl(2) calls to uftdi(4) to access bitbang, MPSSE, CPU_FIFO, and
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.

show more ...

Add the Dresden Elektronik "USB Levelshifter Stick Low Cost" to the
list of known FTDI devices.

https://shop.dresden-elektronik.de/accessories/levelshifter/usb-pegelwandler-stick-basic.html

MFC aft

Add the Dresden Elektronik "USB Levelshifter Stick Low Cost" to the
list of known FTDI devices.

https://shop.dresden-elektronik.de/accessories/levelshifter/usb-pegelwandler-stick-basic.html

MFC after: 1 week

show more ...

Use 2K buffers for IO to help achieve full device speed, rather than the
default wMaxPacketSize (64 or 512 bytes). This actually helps older FTDI
devices (which were USB 1/full speed) more than the

Use 2K buffers for IO to help achieve full device speed, rather than the
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).

show more ...

Support serial speeds up to 12mbaud with newer FTDI chips.

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

Support serial speeds up to 12mbaud with newer FTDI chips.

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.

show more ...

Merge head r233826 through r256722.

IFC @256277

Approved by: ken (mentor)

IFC @ r255692

Comment out IA32_MISC_ENABLE MSR access - this doesn't exist on AMD.
Need to sort out how arch-specific MSRs will be handled.

MFC

Merge from head

IFC @ r255209