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
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
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.
Also replace numbered list with - bulleted so the list entries do not
need to be renumbered as tasks are completed.
Sponsored by: The FreeBSD Foundation
On FDT-enabled platforms check if DTB blob has MAC address configured by
a boot loader. This information passed as a "local-mac-address" or
"mac-address" property of the device node. For USB NICs node
can be found by looking for compatibility string "usbVVV,PPP" where
VVV - vendor id (hex) and PPP - product id (hex)
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D16117
lan78xx_eeprom_read just checked for EEPROM presence then called
lan78xx_eeprom_read_raw if present, and had only one caller. Introduce
lan78xx_eeprom_present to check for EEPROM presence, and use it in the
one place it is needed.
This is used by r334964, which was accidentally committed out-of-order
from my work tree.
Reported by: markj
Sponsored by: The FreeBSD Foundation
Differences between LAN7800 and LAN7850 from the driver's perspective:
* The LAN7800 muxes EEPROM signals with LEDs, so LED mode needs to be
disabled when reading/writing EEPROM. The EEPROM is not muxed on the
LAN7850.
* The Linux driver enables automatic duplex and speed detection when
there is no EEPROM, for the LAN7800 only. With this FreeBSD driver
LAN7850-based adapters without a configuration EEPROM fail to link
(with or without the automatic duplex and speed detection code), so
I have just followed the example of the Linux driver for now.
Sponsored by: The FreeBSD Foundation
Sponsored by: Microchip (hardware)
The GMII control bit ETH_MAC_CR_GMII_EN_ is not documented in
LAN78xx datasheets, but from the permissively licensed header provided
by Microchip it is:
#define ETH_MAC_CR_GMII_EN (0x00080000UL ) // GMII/RGMII Selection
Previously lan78xx_chip_init locked the driver's mutex if not already
locked, but unlocked it only in the case of error. This provided a
fairly clear indication that the function is already called with the
lock held, so just replace it with a lock assertion.
Sponsored by: The FreeBSD Foundation
This driver was developed for the LAN7800 and the register-compatible
LAN7515 and has only been tested on those devices. Adding support for
other members of the family should be straightforward, once we have
devices to test.
With this change the driver will probe but fail to attach due to the
Chip ID check, but will leave a hint leading to the driver that needs
work.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15537
This driver was developed for the LAN7800 and the register-compatible
LAN7515 (found on Raspberry Pi 3B+) and has only been tested on those
devices.
Sponsored by: The FreeBSD Foundation
muge was committed to the tree in r333713 but not yet connected to the
tree, and it crossed paths with the migration to using ck.
Sponsored by: The FreeBSD Foundation
Microchip provided a permissively-licensed lan78xx header, which has
an 'ETH_' prefix on most definitions. Follow suit in our driver.
Sponsored by: The FreeBSD Foundation
This driver supports two Microchip USB-Ethernet controllers:
LAN7800 USB 3.1 to 10/100/1000 Mbps Ethernet
LAN7515 USB 2 to 10/100/1000 Mbps Ethernet with built-in USB hub
The LAN7515 is the Ethernet controller on the Raspberry Pi 3B+.
At present there is no datasheet for the LAN7515, but it is effectively
a USB 2 hub combined with a LAN7800 controller. A comprehensive LAN7800
datasheet is at http://www.microchip.com/wwwproducts/en/LAN7800.
This driver is based on the structure of the smsc(4) driver which
supports Microchip/SMSC's LAN95xx family. (Microchip acquired SMSC
in May 2012.) The Linux lan78xx driver served as a reference for some
functionality and registers.
The 'muge' driver name comes from "Microchip USB Gigabit Ethernet".
I made some style adjustments and minor edits to Arshan's submission.
It will be connected to the build after additional review and testing.
Thanks to Microchip for providing a number of Evaluation Boards (EVBs)
for development and testing.
Submitted by: Arshan Khanifar
Reviewed by: hselasky (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15168
Per the datasheet, the BUSY bit must be set when reading or writing PHY
registers. From Linux commit 80928805babf.
Submitted by: Arshan Khanifar
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15217
In smsc_phy_init function, when the driver was trying to reset PHY, it
didn't poll for the correct bit (BMCR_RESET) to be cleared. Instead, it
anded it with MII_BMCR (which is 0), so it just exited the loop.
This issue was fixed in Linux in commit d94609200069.
Submitted by: Arshan Khanifar
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
network device pointer might be NULL. Wait for any pending tasks to
complete before calling axge_stop().
MFC after: 1 week
Sponsored by: Mellanox Technologies
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Initially, only tag files that use BSD 4-Clause "Original" license.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D13133
To accomodate all variaties of Pi DTS files floating around
we look for MAC address property either in DTS node for
USB ethernet (if it exists) or at predefined path
".../usb/hub/ethernet".
After r324184 smsc_fdt_find_eth_node started to return node
with compatibility string "usb424,ec00" as an eth node.
In imported GNU dts files this node still does not have
MAC address related property, and therefor following check for
"mac-address" and "local-mac-address" fails.
To make this logic more robust do not just search for the node
but also make sure it has required property, so if node with
accepted compatibility string exists but doesn't have the
property we fall back to looking for hardoded path mentioned above.
- Added more compatibility strings to drivers not yet converted
- Added new RPI platform code compatibility string to match the ones used
upstream
- Adapted RPI and RPI2 DTS to match the new platform code compatibility
string
The goal is to use the upstream DTBs as a replacement for our custom one.
This is now possible with these changes.
Additionally, as the RPI firmware automatically chooses the right DTB for
us, this would allow to have one common armv6 kernel for RPI0 and RPI1
(BCM2835-based), and one common armv7 kernel for RPI2 v1.1 (BCM2836-based),
and RPI2 v1.2 / RPI3 (BCM2837-based).
Submitted by: Sylvain Garrigues <sylgar@gmail.com>
Differential Revision: https://reviews.freebsd.org/D12360
