On Sun, Oct 28, 2007 at 10:00:51PM -0400, Corey Osgood wrote:
If dev is the same as in v2 this won't work. dev is not just the config port (e.g. 0x2e) but a struct which contains other stuff, I think.
dev is just the port in this case, it's not like v2.
OK, we should rename the variable 'port' then maybe. It's confusing otherwise.
Either way, I think you can safely apply 0x87 twice, even if it's only needed once (see superiotool). Please test this on hardware, and if it works (I'm pretty sure it will), just use the already existing 0x87 0x87 function.
I would much, MUCH rather apply it once and have it succeed then do it twice and have it fail, especially if by that point it slips my mind why it might have failed. I'll test it out on hardware once the rest of the code builds (and if I don't, poke me a reminder).
Sure, the safe way is to do it only once. FWIW, with some other Super I/Os I have tested that applying the sequence twice is non-critical (forgetting the exit sequence _does_ cause problems though!)
enable_serial() only? Hardcoding the device name in function names was an ugly workaround in v2, AFAIK. It's not really needed in v3 (?)
Hmm, very true, but we also have to remember the case of multiple superios, where one might be connected and the other not, such as my
Yeah.
pcchips board with the vt8235 (integrated superio) and a separate superio. Even though we don't care about the other one, we still have to handle it, since it is there for some purpose, be it sensors or southbridge.
Maybe we should have a _list_ of Super I/O init functions which are called? That way we could even handle 3 or 4 Super I/Os...
I'd rather like to see some common code which calls an _enable_serial function which is "registered" to the framewrok via structs like we use in most of the other code, e.g.
static void enable_serial(u8 dev, u8 serial, u16 iobase) { // ... }
static struct foo bar = { .init = &enable_serial, };
or something along those lines...
Good suggestion. Perhaps super ios should work something like pci devices, where if no .xxx is explicitly provided, a default routine is used.
Yeah, that would be perfect!
The LDNs are listed in the dts anyway, and probably also in the superio.c file (if modeled similar as the 'smscsuperio' code in v2).
Just have to figure out how to USE them from the dts, and we'll be golden ;)
Yeah, that's a bit of a problem. Haven't tried if it's possible, yet.
Maybe a file lib/superio.c or something which contains the common framework? Or superio/framework/*? Dunno...
Again, I think we can reuse some parts of the pci device framework. I'll toy with it once I can get the rest of ram init building/working, if no one else does.
I'll see what I can come up with. Expect a patch Soon (tm).
Uwe.