[LinuxBIOS] [PATCH]Fintek F71805f for LinuxBIOSv3

Uwe Hermann uwe at hermann-uwe.de
Mon Oct 29 11:07:00 CET 2007

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

> > 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


> 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).

http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071029/cf41c004/attachment.sig>

More information about the coreboot mailing list