ron minnich wrote: > > Dynamic superio probing only makes any sense to me if it can be used > > verbatim on each and every superio > > yes, but having a single superio device structure in the static > tree is what requires dynamic devices. We're not probing. > We are actually just creating devices on demand. Those are two > different things.
Right. Who knows what should be demanded? I would like the mainboard dts to be the source. > Plus, the weird thing on a superio: even if you don't want a > function (e.g. serial) it's important to make sure you turn certain > pnp functions off in some cases -- > so you may want that pnp function controlled, even if you do not > use it. Yes, that's why I think all functions of the chip should be listed somewhere (superio dts) but the ones that actually are enabled somewhere else (mainboard dts).. > Remember the rule: one dts -> one device. I tend to like one dts -> one chip. But as long as dtses can pull in other dtses we both win. .. > so we get a new dynamic device for each pnp function. > > Making one device for each pnp function, we will need one dts for > each pnp function. This is very easy to do, although it will be a > bit of work. But now is the time to do it if we want to do it. I am > not convinced we want to do it. It will end up being a lot of files, which is a little clumsy. I'd like to roll it into one file.. I guess we've gone back and forth on this. I guess dtc is the bottleneck because it only deals with one struct per input file? > I'd rather put the effort into getting the k8 to work, Or GeodeLX, C7, or Core2. There's plenty of unfinished stuff in v3 now. :) SCNR. //Peter -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
