| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
PR: 281962
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds support for AMD Ryzen 7 "Phoenix" processors (family 0x19,
model 0x70-0x7f) to the amdsmn(4) and amdtemp(4) drivers. This
enables temperature readings of these CPUs via sysctl.
The sensors function identically to those for the "Raphael" processors
(model 0x60-0x6f); only the PCI device ID differs.
PR: kern/280942
Relnotes: yes
MFC after: 3 days
|
|
|
|
| |
Sponsored by: Netflix
|
|
|
|
|
|
|
|
| |
Tested on AMD Threadripper 7960X.
PR: kern/278311
Tested by: jbo
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the API of pci_cfgreg(read|write) to add a domain
argument (referred to as a segment in ACPI parlance) (note that this
is not the same as a NUMA domain, but something PCI-specific). This
does not yet enable access to domains other than 0, but updates the
API to support domains.
Places that use hard-coded bus/slot/function addresses have been
updated to hardcode a domain of 0. A few places that have the PCI
domain (segment) available such as the acpi_pcib_acpi.c Host-PCI
bridge driver pass the PCI domain.
The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on
domain 0 since they provide APIs to their binary blobs that only
permit bus/slot/function addressing.
The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do
not support multiple domains.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
|
|
|
|
| |
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
|
|
|
|
|
|
|
|
| |
Zen 4 support, tested on Ryzen 9 7900
Reviewed by: imp (previous version), mhorne
Approved by: mhorne
Obtained from: http://jyurai.ddo.jp/~amorita/diary/?date=20221102#p01
Differential Revision: https://reviews.freebsd.org/D41049
|
|
|
|
|
|
|
|
|
|
|
|
| |
On an EPYC 7313P, the temperature reported by amdtemp was off, because
the offset was not applied. Turns out it needs to be applied with one
more condition: https://lkml.org/lkml/2023/4/13/1095
Reviewed by: mhorne
Tested by: mike.jakubik@gmail.com
MFC after: 1 week
Sponsored by: https://www.patreon.com/valpackett
Pull Request: https://github.com/freebsd/freebsd-src/pull/754
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
It seems to be needed only to serialize very old K8 registers access.
Introduce separate lock for that and remove Giant dependency.
MFC after: 2 weeks
|
|
|
|
| |
Sponsored by: Rubicon Communications, LLC ("Netgate")
|
|
|
|
|
|
|
|
| |
This reverts commit 266f97b5e9a7958e365e78288616a459b40d924a, reversing
changes made to a10253cffea84c0c980a36ba6776b00ed96c3e3b.
A mismerge of a merge to catch up to main resulted in files being
committed which should not have been.
|
|
|
|
|
|
| |
This is the November update to vendor/wpa committed upstream 2021-11-26.
MFC after: 1 month
|
|
|
|
|
|
|
|
| |
While it still looks like previous code worked by coincidence, this
change broke things even more instead of fixing.
Reported by: avg@
MFC after: 1 week
|
|
|
|
|
|
| |
Before this device unit number match was coincidental and broke if I
disabled some CPU device(s). Aside of cosmetics, for some drivers
(may be considered broken) it caused talking to wrong CPUs.
|
|
|
|
|
|
|
|
|
|
| |
Add missing model numbers M20h (Dali, Zen1), M60H (Renoir, Zen2), and
M90H (Van Gogh, Zen2).
Submitted by: Greg V <greg AT unrelenting.technology>
Notes:
svn path=/head/; revision=368587
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zen 3 "Vermeer" support, tested on Ryzen 9 5950X.
Model numbers from https://en.wikichip.org/wiki/amd/cpuid "Extended
Model" column.
Submitted by: Greg V <greg AT unrelenting.technology>
Differential Revision: https://reviews.freebsd.org/D27552
Notes:
svn path=/head/; revision=368586
|
|
|
|
|
|
|
|
|
| |
PR: 249864
Reported by: Florian Millet <florian.millet AT laposte.net>
Tested by: Florian Millet
Notes:
svn path=/head/; revision=366136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_unreachable doesn't raise any compile-time warnings/errors on its
own, so problems with its usage can't be easily detected. While it would be
nice for this situation to change and compilers to at least add a warning
for trivial cases where local state means the instruction can't be reached,
this isn't the case at the moment and likely will not happen.
This commit adds an __assert_unreachable, whose intent is incredibly clear:
it asserts that this instruction is unreachable. On INVARIANTS builds, it's
a panic(), and on non-INVARIANTS it expands to __unreachable().
Existing users of __unreachable() are converted to __assert_unreachable,
to improve debuggability if this assumption is violated.
Reviewed by: mjg
Differential Revision: https://reviews.freebsd.org/D23793
Notes:
svn path=/head/; revision=361011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT
Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718
Notes:
svn path=/head/; revision=358333
|
|
|
|
|
|
|
| |
I intended to remove this before committing, but neglected to.
Notes:
svn path=/head/; revision=357194
|
|
|
|
|
|
|
|
|
|
| |
Probe Family 17h CPUs for up to 4 (Zen, Zen+) or 8 (Zen2) CCD temperature
sensors. These were discovered by Ondrej Čerman
(https://github.com/ocerman) and collaborators experimentally, and are not
currently documented in any datasheet I have access to.
Notes:
svn path=/head/; revision=357190
|
|
|
|
|
|
|
| |
No functional change intended.
Notes:
svn path=/head/; revision=357189
|
|
|
|
|
|
|
|
| |
PR: 239607
Reported by: "drclaw" <drclaw AT gmail.com>
Notes:
svn path=/head/; revision=350624
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Family 15h is a bit of an oddball. Early models used the same temperature
register and spec (mostly[1]) as earlier CPU families.
Model 60h-6Fh and 70-7Fh use something more like Family 17h's Service
Management Network, communicating with it in a similar fashion. To support
them, add support for their version of SMU indirection to amdsmn(4) and use
it in amdtemp(4) on these models.
While here, clarify some of the deviceid macros in amdtemp(4) that were
added with arbitrary, incorrect family numbers, and remove ones that were
not used. Additionally, clarify intent and condition of heterogenous
multi-socket system detection.
[1]: 15h adds the "adjust range by -49°C if a certain condition is met,"
which previous families did not have.
Reported by: D. C. <tjoard AT gmail.com>
PR: 234657
Tested by: D. C. <tjoard AT gmail.com>
Notes:
svn path=/head/; revision=342977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the AMD family 17h temperature reporting based on AMD Tech Doc 56255
OSRR, section 4.2.1.
For CPUS w/CUR_TEMP_RANGE_SEL set, scale the reported temperature into the
range -49..206; i.e., subtract 49°C.
Submitted by: gallatin@
Reported by: bcran@
Reviewed by: me (long ago)
MFC after: 22.57 seconds
Relnotes: yea
Differential Revision: https://reviews.freebsd.org/D16855
Notes:
svn path=/head/; revision=340426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported, tested, and patch supplied by Johannes.
There may be future work to do to support multiple sensors, but for now, any
sensor at all is a strict improvement for Ryzen 2 systems.
PR: 228480
Submitted by: Johannes Lundberg <johalun0 AT gmail.com> (earlier version)
Reported by: deischen@, Johannes, and numerous others
MFC after: 3.72 days
Notes:
svn path=/head/; revision=340425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove unused and easy to misuse PNP macro parameter
Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.
Mostly done with the coccinelle 'spatch' tool:
$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);
@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);
$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci
(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)
Tinderbox'd (-DMAKE_JUST_KERNELS).
Approved by: re (glen)
Notes:
svn path=/head/; revision=338948
|
|
|
|
|
|
|
|
|
|
| |
I was not aware Warner was making or planning to make forward progress in
this area and have since been informed of that.
It's easy to apply/reapply when churn dies down.
Notes:
svn path=/head/; revision=338037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.
Mostly done with the coccinelle 'spatch' tool:
$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);
@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);
$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci
(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)
Tinderbox'd (-DMAKE_JUST_KERNELS).
Notes:
svn path=/head/; revision=338035
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Notes:
svn path=/head/; revision=326255
|
|
|
|
|
|
|
|
|
|
|
|
| |
An eventual devd(8) or other component should be able to scan buses and
automatically load drivers that match device ids described in this metadata.
Reviewed by: imp
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12364
Notes:
svn path=/head/; revision=323586
|
|
|
|
|
|
|
|
|
|
|
| |
Some systems have hostbs that do not match our PCI device id criteria.
Detect and ignore these devices in probe.
PR: 218264
Sponsored by: Dell EMC Isilon
Notes:
svn path=/head/; revision=323195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sensor value is formatted similarly to previous models (same
bitfield sizes, same units), but must be read off of the internal
System Management Network (SMN) from the System Management Unit (SMU)
co-processor.
PR: 218264
Reported and tested by: Nils Beyer <nbe AT renzel.net>
Reviewed by: avg (no +1), mjoras, truckman
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12217
Notes:
svn path=/head/; revision=323185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After r285994, sysctl(8) was fixed to use 273.15 instead of 273.20 as 0C
reference and as result, the temperature read in sysctl(8) now exibits a
+0.1C difference.
This commit fix the kernel references to match the reference value used in
sysctl(8) after r285994.
Sponsored by: Rubicon Communications (Netgate)
Notes:
svn path=/head/; revision=300421
|
|
|
|
|
|
|
|
|
|
| |
This adds support to CPU found in PC Engines APU2 series.
MFC after: 3 weeks
Sponsored by: Rubicon Communications (Netgate)
Notes:
svn path=/head/; revision=298270
|
|
|
|
|
|
|
|
| |
Submitted by: Remy Nonnenmacher <remy.nonnenmacher@activnetworks.com>
MFC after: 1 week
Notes:
svn path=/head/; revision=273034
|
|
|
|
|
|
|
|
|
| |
PR: 186587
Submitted by: David Rufino <david.rufino at gmail.com>
MFC after: 2 weeks
Notes:
svn path=/head/; revision=263169
|
|
|
|
|
|
|
| |
CPU: AMD A10-5700 APU with Radeon(tm) HD Graphics (3393.89-MHz K8-class CPU)
Notes:
svn path=/head/; revision=254924
|
|
|
|
|
|
|
|
|
|
| |
device_method_t arrays
Reviewed by: cognet
Approved by: cognet
Notes:
svn path=/head/; revision=246128
|
|
|
|
|
|
|
|
|
|
|
| |
unit 0 would in fact disable all units.
This reverts r241856
Approved by: cperciva (implicit)
Notes:
svn path=/head/; revision=241885
|
|
|
|
|
|
|
|
|
|
|
| |
device drivers that used to provide this feature.
Reviewed by: des
Approved by: cperciva
MFC after: 1 week
Notes:
svn path=/head/; revision=241856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove all attempts to guess physical temperature using DiodeOffset.
There are too many reports that it varies wildly depending on motherboard.
Instead, if it is known to scale well and its offset is known from other
temperature sensors on board, the user may set "dev.amdtemp.0.sensor_offset"
tunable to compensate the difference. Document the caveats in amdtemp(4).
- Add a quirk for Socket AM2 Revision G processors. These processors are
known to have a different offset according to Linux k8temp driver.
- Warn about Family 10h Erratum 319. These processors have broken sensors.
- Report temperature in more logical orders under dev.amdtemp node. For
example, "dev.amdtemp.0.sensor0.core0" is now "dev.amdtemp.0.core0.sensor0".
- Replace K8, K10 and K11 with official processor names in amdtemp(4).
Notes:
svn path=/head/; revision=232090
|
|
|
|
|
|
|
| |
Reported by: kris
Notes:
svn path=/head/; revision=197205
|
|
|
|
| |
Notes:
svn path=/head/; revision=197103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Improve newer AMD processor support (Family 0Fh Revision F and later).
- Adjust offset if DiodeOffet is set and valid. Note it is experimental
but it seems to give us more realistic temperatures. Newer Linux driver
blindly adds 21C for Family 0Fh desktop processors, however.
- Always populate dev.cpu and dev.amdtemp sysctl trees regardless of probe
order for consistency. Previously, dev.cpu.N.temperature was not populated
if amdtemp was loaded later than ACPI CPU driver and temperatures were not
accessible from dev.amdtemp.N.sensor0 tree for Family 10h/11h processors.
- Read the CPUID from PCI register instead of CPUID instruction to prevent
possible revision mismatches on multi-socket system.
- Change macros and variables to make them closer to AMD documents.
- Fix style(9) nits and improve comments.
Notes:
svn path=/head/; revision=197102
|
|
|
|
|
|
|
|
|
| |
reintroduced after HEAD is reopened for commits by re@.
Approved by: re (kib), attilio
Notes:
svn path=/head/; revision=196403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The newbus lock is responsible for protecting newbus internIal structures,
device states and devclass flags. It is necessary to hold it when all
such datas are accessed. For the other operations, softc locking should
ensure enough protection to avoid races.
Newbus lock is automatically held when virtual operations on the device
and bus are invoked when loading the driver or when the suspend/resume
take place. For other 'spourious' operations trying to access/modify
the newbus topology, newbus lock needs to be automatically acquired and
dropped.
For the moment Giant is also acquired in some key point (modules subsystem)
in order to avoid problems before the 8.0 release as module handlers could
make assumptions about it. This Giant locking should go just after
the release happens.
Please keep in mind that the public interface can be expanded in order
to provide more support, if there are really necessities at some point
and also some bugs could arise as long as the patch needs a bit of
further testing.
Bump __FreeBSD_version in order to reflect the newbus lock introduction.
Reviewed by: ed, hps, jhb, imp, mav, scottl
No answer by: ariff, thompsa, yongari
Tested by: pho,
G. Trematerra <giovanni dot trematerra at gmail dot com>,
Brandon Gooch <jamesbrandongooch at gmail dot com>
Sponsored by: Yahoo! Incorporated
Approved by: re (ksmith)
Notes:
svn path=/head/; revision=196037
|