The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
This seems to be required even if the watchdog is accessed via the common
MMIO space.
Tested on:
- Ryzen 3 3200U APU;
- Ryzen 7 5800X CPU with X570 chipset.
MFC after: 2 weeks
Initialize the FCH SMBus controller for Hygon Dhyana CPU.
Set the vendor of the FCH description via the exact CPU vendor.
Submitted by: Pu Wen <puwen@hygon.cn>
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D23558
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.
Originally, I overlooked that PMIO register 0xc0 has a dual personality.
It can either be S5/Reset Status register or Misc. Fix register (aka
debug status register). The mode is controlled by bit 2 in PMIO
register 0xc4. Apparently there are register programming requirements
for the second personality, so many BIOSes leave the register, after
programming it, in that mode. So, we need to switch the register to the
correct mode.
Additionally, AMDSB8_WD_RST_STS was defined incorrectly as bit 13 while
it is actually bit 25 (and the register's width is 32 bits, not 16).
With this change I see the following in dmesg after a reset by the
watchdog:
amdsbwd0: ResetStatus = 0x42000000
amdsbwd0: Previous Reset was caused by Watchdog
MFC after: 2 weeks
Without the suspend method the watchdog may fire in S1 state. Without
the resume method the watchdog is not re-enabled after returning from S3
state. I observe this on one of my systems.
Not sure if watchdog(4) should participate in the suspend actions.
Right now everything is up to individual drivers.
MFC after: 2 weeks
The driver now fully observes watchdog(9) protocol.
Previously a too large timeout was silently clamped while the correct
behavior is to disable the watchdog and leave the error as is
(i.e. to not report success).
Also, previously a too small value caused the timer to stop while the
correct behavior is to use the minimal supported value.
MFC after: 2 weeks
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.
AMD chipsets have proprietary mechanisms for dicovering resources.
Those resources are not discoverable via plug-and-play mechanisms
like PCI configuration registers or ACPI.
For this reason a chipset-specific knowledge of proprietary registers
is required.
At present there are two FreeBSD drivers that require the proprietary
resource discovery. One is amdsbwd which is a driver for the watchdog
timer in the AMD chipsets. The other is intpm SMBus driver when it
attaches to the newer AMD chipsets where the resources of the SMBus HBA
are not described in the regular PCI way.
In both cases the resources are discovered by accessing AMD PMIO space.
Thus, many definitions are shared between the two drivers.
This change puts those defintions into a common header file.
As an added benefit, intpm driver now supports newest FCHs built into
AMD processors of Family 15h, models 70h-7Fh and Family 16h, models
30h-3Fh.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8004
Most of these are BARs, and we allocate them in their entirety. The one outlier
in this is amdsbwd, which calls bus_set_resource() prior.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D5370 (partial)
Many thanks to Tino <tinotom@gmail.com> for drawing my attention to
this, for doing a lot of testing and providing great feedback.
Many thanks to AMD for continuing to release public specifications for
their chipsets.
PR: kern/157568
Tested by: Tino <tinotom@gmail.com>
MFC after: 1 week
The hardware is compliant with WDRT specification, so I originally
considered including generic WDRT watchdog support, but decided
against it, because I couldn't find anyone to the code for me.
WDRT seems to be not very popular.
Besides, generic WDRT porbably requires a slightly different driver
approach.
Reviewed by: des, gavin, rpaulo
MFC after: 3 weeks
