src/sys/dev/amdsbwd, branch release/13.2.0

amdsbwd(4): Fix a typo in a source code comment

2022-06-10T12:32:22Z

- s/accross/across/ (cherry picked from commit 68c0bd3e3f45e030d48b354d7444934ca381a07e)

amdsbwd: always enable watchdog register decoding

2021-12-27T11:37:29Z

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. (cherry picked from commit cca0d3bbd8c9f8b50c6940c33704a6c8c464b68f)

amd*: clean up empty lines in .c and .h files

2020-09-01T21:39:19Z

amdsbwd, intpm: Add Hygon Dhyana support.

2020-02-13T19:09:24Z

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 MFC after: 1 week Differential revision: https://reviews.freebsd.org/D23558

Extract eventfilter declarations to sys/_eventfilter.h

2019-05-20T00:38:23Z

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.

amdsbwd: fix reboot status reporting

2018-05-05T05:22:11Z

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

amdsbwd: add suspend and resume methods

2018-05-03T15:33:18Z

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

[amdsbwd] teach amdsbwd that it has options

2018-04-24T13:07:17Z

AMDSBWD_DEBUG was previously checked for as a #define but it was not possible to define it Reviewed by: kevans Discussed with: kenm

amdsbwd: fix handling of timeout values beyond the supported range

2018-01-10T17:35:00Z

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

sys/dev: further adoption of SPDX licensing ID tags.

2017-11-27T14:52:40Z

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.