cpufreq: Design doc for the changes
Needs ReviewPublic
Actions

Authored by imp on Oct 13 2023, 5:43 PM.

Details

Reviewers

Summary

Here's a breif design doc for the chagnes.

Note: this is an experiment to see if there's an easy way to attach some kind of 'letter' for larger reviews and/or to document this and keep track of progress (not sure all of these should be in the same doc). This is a snapshot and so all the boxes aren't yet ticked since they aren't done.

https://gitlab.com/bsdimp/freebsd/-/blob/acpi_cppc/design/cpufreq.adoc?ref_type=heads

contains a rendered version which I'll try to keep up to date.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 54018
Build 50908: arc lint + arc unit

Event Timeline

imp requested review of this revision.Oct 13 2023, 5:43 PM

imp created this revision.

Harbormaster completed remote builds in B53972: Diff 128745.Oct 13 2023, 5:43 PM

imp edited the summary of this revision. (Show Details)Oct 13 2023, 5:47 PM

imp added a reviewer: jhb.

imp edited the summary of this revision. (Show Details)Oct 13 2023, 5:50 PM

jhb added inline comments.Oct 13 2023, 10:20 PM

design/cpufreq.adoc
33	Here what we want is a way to disable a driver rather than disabling a device. Something like 'hint.pt4cc.disabled=1' that doesn't take a unit maybe, though it would be nice to move away from hints for this. This particular case is harder since the driver won't have a name. One way we could maybe keep the driver name is to use a "type" IVAR on the "cpu" bus, and add an unnamed node with the "type" set to CPUFREQ and make the drivers require that IVAR in their probe routine. This might be a bit less POLA-violating and might allow the existing hints to work while still getting rid of the identify routines? That is, we would be using the "type" IVAR similar to how PCI drivers use the "devid" IVAR.