On Thu, Mar 24, 2005 at 07:59:21AM -0800, Patrick Mochel wrote: > > On Thu, 24 Mar 2005, Pavel Machek wrote: > > > Hi! > > > > > > Just for clarity's sake, what are you thinking should happen to MTRR > > > > support? > > > > > > Become more componentized. We need a better way to represent optional > > > features of any device, but in particular CPUs. We should never be calling > > > it directly; we should be looping over the feature drivers bound to a 'CPU > > > Driver' and suspending them. > > > > Actually, no. > > > > mtrr's are cpu local. That means they need to be handled by CPU > > hotplug framework. I guess we should just drop them from "normal" > > device trees, and create something per-CPU. > > Sorry, it was late and that explanation sucked. > > - Every CPU has a set of optional features that it supports. > > - MTRRs are an optional feature that a CPU may support. > > - When the MTRR driver is loaded, a data structure should be allocated for > each CPU and added to a list. > > - The list that the per-CPU MTRR data structure is added to could be part > of a 'CPU driver'. > > - We should be looping over the set of optional features that a CPU > supports to suspend/resume them, rather than calling them directly. Don't sysdev_suspend and sysdev_resume do this already? > > Perhaps plain old notification list is enough for this one. > > It's possible, but notification lists present some problems. Like the fact > they use a hard-coded set of events in a global header file. They are good > only for a certain set of events. > > It's damn simple to create a struct type for CPU features and a method > contained in each one for cpu offline/online. I would suggest adding a > list_head to struct cpu (include/linux/cpu.h) called 'features', then > having things like MTRR add themselves to that list. Why is the existing sysdev auxiliary driver support not sufficient? Last time I checked, cpufreq uses it for this kind of purpose. Nathan
