this to 2k to prevent them from being truncated and ignored. It
appears to be a sanity check only, but bumping it to 2k allows both of
my iic hid devices to be parsed and the second one to work...
After r351243 when ALTQ was enabled in the kernel, the inline functions
in ifq.h would not have full type information as if_var.h was not
included.
Given usb_ethernet.h already includes all the various headers (which)
is the cause of the problem here, add if_var.h to it. This fixes the
builds again.
Reported by: CI system, e.g. FreeBSD-head-aarch64-LINT
order to have struct mii_data available. However, it only really needs
a forward declaration of struct mii_data for use in pointer form for
the return type of a function prototype.
Custom kernel configuration that have usb and fdt enabled, but no miibus,
end up with compilation failures because miibus_if.h will not get
generated.
Due to the above, the following changes have been made to usb_ethernet.h:
* remove the inclusion of mii headers
* forward-declare struct mii_data
* include net/ifq.h to satify the need for complete struct ifqueue
Reviewed by: ian
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D21293
with Communication Device Class Ethernet Emulation Model (CDC EEM).
The driver supports both the device, and host side operation; there
is a new USB template (#11) for the former.
This enables communication with virtual USB NIC provided by iLO 5,
as found in new HPE Proliant servers.
Reviewed by: hselasky
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Hewlett Packard Enterprise
Enable this for the NovAtel OEMv2 GPS receiver.
Not fixed: The receiver shows up as "<Interface 0>" in the device
tree, because that is literally what the descriptor-string is.
Reviewed by: hselasky@
While at it fix an invalid memory access issue when attaching external
USB HUBs, which are not mapped by ACPI, due to missing status check
when calling AcpiGetObjectInfo() from acpi_usb_hub_port_probe_cb().
Sponsored by: Mellanox Technologies
This adds ACPI device path on devinfo(8) output and
show value of _UPC(usb port capabilities), _PLD (physical location of device)
when hw.usb.debug >= 1 .
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D20630
rename the source to gsb_crc32.c.
This is a prerequisite of unifying kernel zlib instances.
PR: 229763
Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>
Differential Revision: https://reviews.freebsd.org/D20193
asserted. Some development boards for example will reset on DTR,
and some radio interfaces will transmit on RTS.
This patch allows "stty -f /dev/ttyu9.init -rtsdtr" to prevent
RTS and DTR from being asserted on open(), allowing these devices
to be used without problems.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20031
if a USB transfer is cancelled that we need to fake a completion event.
Implement missing support in ugen_fs_copy_out() to handle this.
This fixes issues with webcamd(8) and firefox.
MFC after: 3 days
Sponsored by: Mellanox Technologies
This is a curious small widget for which I might write a driver.
It is bridge between USB HID interface and I2C interface plus some
GPIO pins.
MFC after: 2 weeks
all-ones then carving out blocks of zeroes where specified values go, init
it to all-zeroes, put in ones where values need to be masked, then use it
as value &= ~sc_led_modes_mask. In addition to being more idiomatic, this
means everything related to FDT data is initialized to zero along with the
rest of the softc, and that allows removing some #ifdef FDT sections and
wrapping the whole muge_set_leds() function in a single ifdef block.
This also deletes the early-out from muge_set_leds() when an eeprom exists.
Even if there is an eeprom with led config in it, the fdt data (if present)
should override that, because the user is in control of the fdt data.
OTP registers (because the user is in control of the fdt data). Remove the
early returns from the code that tries to find a good mac address, so that
the execution always flows through the routine to get an address from FDT
data last, when on FDT-enabled systems.
the device instance, and to get the MAC address for the device instance.
The ad-hoc code this replaces could find the wrong instance if multiple
devices were present.
Also use LED mode settings from the FDT to set the PHY.
From v3 of the patch submitted in the PR.
I moved the sc_led_modes and sc_led_modes_mask default setting outside
of the #ifdef FDT case.
PR: 237325
Submitted by: Ralf <iz-rpi03@hs-karlsruhe.de>
Reviewed by: ian
MFC after: 2 weeks
MFC with: r348001
Event: Waterloo Hackathon 2019
Differential Revision: https://reviews.freebsd.org/D20325
Also apply some style(9) and remove the message about EEPROM configuration
(if there's an EEPROM the hardware handles LED configuration itself).
PR: 237325
Reviewed by: ian
MFC after: 2 weeks
Submitted by: Ralf <iz-rpi03@hs-karlsruhe.de>
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
pollution substantially.
EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).
As a side effect of reduced header pollution, many .c files and headers no
longer contain needed definitions. The remainder of the patch addresses
adding appropriate includes to fix those files.
LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
sys/mutex.h since r326106 (but silently protected by header pollution prior
to this change).
No functional change (intended). Of course, any out of tree modules that
relied on header pollution for sys/eventhandler.h, sys/lock.h, or
sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped.
FDT data is sometimes used to configure usb devices which are hardwired into
an embedded system. Because the devices are instantiated by the usb
enumeration process rather than by ofwbus iterating through the fdt data, it
is somewhat difficult for a usb driver to locate fdt data that belongs to
it. In the past, various ad-hoc methods have been used, which can lead to
errors such applying configuration that should apply only to a hardwired
device onto a similar device attached by the user at runtime. For example,
if the user adds an ethernet device that uses the same driver as the builtin
ethernet, both devices might end up with the same MAC address.
These changes add a new usb_fdt_get_node() helper function that a driver can
use to locate FDT data that belongs to a single unique instance of the
device. This function locates the proper FDT data using the mechanism
detailed in the standard "usb-device.txt" binding document [1].
There is also a new usb_fdt_get_mac_addr() function, used to retrieve the
mac address for a given device instance from the fdt data. It uses
usb_fdt_get_node() to locate the right node in the FDT data, and attempts to
obtain the mac-address or local-mac-address property (in that order, the
same as linux does it).
The existing if_smsc driver is modified to use the new functions, both as an
example and for testing the new functions. Rpi and rpi2 boards use this
driver and provide the mac address via the fdt data.
[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.txt
Differential Revision: https://reviews.freebsd.org/D20262
Ampere eMAG systems have XHCI just described in ACPI, not on PCI.
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: andrew
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19986
RTL8152 (chip version URE_CHIP_VER_4C10) doesn't
have hardwired MAC address, in other words, it is all zeros.
This commit fixes it by setting random MAC address
when MAC address is all zeros.
Reviewed by: kevlo
Differential Revision: https://reviews.freebsd.org/D19856
Both linux and u-boot sources for RTL8152 driver has this value.
RTL8152 USB ethernet is used in NanoPI R1 board as second ethernet.
This fixes for me RTL8152 USB ethernet not detected problem after
reboot on NanoPI R1 board.
Both NetBSD and OpenBSD have a wrong value so far.
frame header and data.
This will fix 'Mysterious OLPC stuff' for received frames and wrong
CCMP / TKIP / data decoding for transmitted frames in net/wireshark
dissector.
While here, drop unneeded comment - net80211 handles padding requirements
for Tx & Rx without driver adjustment.
Tested with D-Link DWA-140 rev B3, STA mode.
MFC after: 1 week
Also, pass control frames to the host while in MONITOR mode and / or
when promiscuous mode is enabled.
Tested with Netgear WG111 v3 (RTL8187B), STA / MONITOR modes.
MFC after: 2 weeks
- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.
- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.
Tested with Netgear WG111 v3 (urtw(4)), STA mode.
MFC after: 2 weeks
Marvell XHCI is in fact generic-xhci, so move the driver and
add the compatible string.
While here, get and enable the phy if the dtb provide one.
The xhci bindings state that phys should be in a 'phys' property but
Marvell DTS uses 'usb-phy', only add support for 'usb-phy' for now.
Sponsored-by: Rubicon Communications, LCC ("Netgate")
This is a "fake" phy that handle regulator, clocks and reset gpio.
Only clock and regulator is supported for now.
Sponsored-by: Rubicon Communications, LCC ("Netgate")
