grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH] PCI serial card support


From: Dugger, Donald D
Subject: RE: [PATCH] PCI serial card support
Date: Wed, 5 Nov 2008 07:37:50 -0800

>-----Original Message-----
>...
>> what happens if you have 2 different PCI cards installed,
>
>Then serial.mod can handle multiple terminals (it already 
>does, just not for PCI cards) via `serial' command, and use 
>the PCI calls to gather info about them whenever they're to be used.
>

Hmmm, this is getting a litte more complex than I had hoped but
so be it.  The problem is that to do this you need more than just
a PCI ID to base_baud map, now you have to be able to enumerate
serial devices, both multi-port and multi-function, so you can
match different terminal ports to their resources.  The code to do
this is moderately complex but, fortunately, the code already
exists in the Linux driver, I can just copy that code.  I know that
that code needs sub-vendor and sub-device IDs which I don't think
are exposed by the current grub PCI code so I'll have to expand
the PCI code just a little.

My thought was that we leave units 0 - 3 as the legacy ports
(whether they exist or not) and then number the PCI serial
ports that we find as units 4 and up.  I have a patch for a
simple PCI ID to base_baud map, I'll to to work on expanding
that patch.

Also, I'd like to modify the `serial' command so that typing that
command with no arguments lists out the serial ports availale,
I think that would be a usefull capability.

>> what happens if you find a serial card that isn't on the list,
>
>Does this issue happen with all serial cards, or just some?  
>If it happens with all, I guess it could just issue an error 
>and let the user know that we need feedback on how to add this one?
>
>> what about Express cards, etc.
>
>What do you mean?

I don't know anything about Express cards, if they sit on the
PCI bus with normal BDF's then there is no problem, if they
interface through some other means then supporting them will
get interesting.

>
>--
>Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will 
>decide when (and
>  how) you may access your data; but nobody's threatening your 
>freedom: we
>  still allow you to remove your data and not access it at all."
>
>
>_______________________________________________
>Grub-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/grub-devel
>



--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
address@hidden
Ph: (303)443-3786 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]