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.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
signature.asc
Description: Digital signature
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
