On Wed, May 19, 2010 at 09:16:24AM -0500, Praveen Kalamegham wrote:
> Greg KH wrote:
> >It used to be in the PCI Hotplug spec, but note that the last time I
> >read that, was back in 2001 or so. I could go dig through the PCI
> >Hotplug spec again if you really can't find it.
> >
> I have looked through the PCI Hotplug Spec (1.1 dated 6/20/2001) and
> cannot find any reference to this. Is this the correct spec?
Yes, I think it is.
Ugh, I just dug through this spec, and the Standard PCI Hotplug
Controller spec, and you are right, I can't see anything that talks
aobut video devices here.
I wonder where I got the idea that we couldn't do this. Maybe it was
for the very old, Compaq PCI Hotplug controller spec, which pre-dated
the PCI standard by a few years. Or perhaps the ACPI PCI Hotplug spec
(no, I don't want to go read the ACPI spec to verify that...)
Anyway, the question about POST issues with bioses seem to be addressed
in section 4.1.4 of the PCI Hotplug spec, that states:
4.1.4 Add-in Card Option ROMs
Each operating-system vendor must specify the policy for the treatment of add-in card
option ROM code after an add-in card is hot-inserted. Possible alternatives include, but
are not limited to, the following:
1. Execution of an Open Firmware code image
2. Require that option ROM functionality be provided by some other means, for
example, duplicating the function in the add-in card driver
Implementation Note: Replacing Functionality of Option ROMs on Add-in Cards
Some add-in card option ROMs establish essential operating parameters of the card. If
these ROMs contain an image of Code Type 0 (Intel x86, PC-AT compatible), the code
stored in this image is designed to execute during initial power-on, before the operating
system is loaded, and, in general, cannot be executed during a hot-insertion operation.
If the operating-system vendor specifies that option ROMs are not executed after a hot-
insertion, the add-in card vendor must use the capabilities and functions available
through the operating system at run-time to replace the functionality provided by these
option ROMs at boot-time. For example, the add-in card vendor may choose to
implement this function by adding it to the add-in card driver itself, or by creating a
separate card-specific configuration application that communicates with the add-in
card driver.
Also, in the next section, 4.1.5 entitled "Add-in Card Driver
Requirements", the last paragraph states:
Third, one alternative for the treatment of PCI options ROMs is
for the operating-system vendor to require that the add-in card
driver replace any necessary functionality of option ROMs after
a hot-insertion event (see Section 4.1.4).
So it looks like we are safe to try to do this now. If things "break",
without a BIOS option rom running, well, odds are suspend/resume didn't
work either on this platform, so there are bigger issues here.
> >Yes, they might not, but then again, they might, it all depends on the
> >video card itself. Which was why the spec said that VGA-like devices
> >could not be hotplugged, and hence, we try to check that in the kernel
> >code.
> I don't see any reference to this rule in the most recent version of
> the spec. If it is indeed not present anymore, can we remove this
> check?
Let's try it and see what happens :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
