[SeaBIOS] [PATCH] seabios: call pci_init_device on resume

[Gerd Hoffmann]

On Fr, 2013-12-20 at 00:40 +0200, Michael S. Tsirkin wrote:
> On Thu, Dec 19, 2013 at 11:32:03PM +0100, Laszlo Ersek wrote:
> > On 12/19/13 23:16, Michael S. Tsirkin wrote:
> > 
> > > I suspect we need to init more devices, but I need to look some
> > > more into this. Basically whatever OS does not restore, we have to.
> > 
> > I don't think that implication is necessarily true. Just because neither
> > restores some device state currently doesn't imply the firmware should
> > restore it. The OS is much better equipped to restore complex state;
> 
> If you look at my patch, there's nothing complex there.

You don't restore state, you re-initialize things.  That is something
different.

In case of the i440fx northbridge this probably is pretty much the same
as the smbase + pmbase register don't change at runtime.  That isn't
true for other devices though.

> > The Platform Init spec 1.2.1 says in Vol5, 8.5.1.3.1 DXE and the S3
> > Resume Boot Path,
> > 
> >   The ACPI specification only requires the BIOS to restore chipset and
> >   processor configuration. [...]
> 
> All of PIIX and Q35 is part if the chipset though.

I doubt this includes all piix/q35 onboard devices (ide/sata, usb,
nic, ...).

The smbios/pmbase register bases are a special case as these registers
are needed do handle suspend and resume correctly.  I suspect this is
the reason why they are kind-of hidden (i.e. not implemented as normal
pci i/o bars) in the first place.

Also chipset-specific configuration goes into this category I expect.
Basically all the stuff you can configure in the bios setup utility on
physical hardware, i.e. which LPC devices (serial, parallel, ...) are
enabled/disabled, whenever the storage controller operates in legacy
(aka IDE) or native (AHCI) mode, ...

I think we should go go a minimum patch which specifically reinitializes
the registers which actually need reinitialization.

> > I'm not sure which part of the ACPI spec they refer to, and of course
> > this statement may not be overly accurate either, but it does seem to
> > limit the firmware's responsibility.
> > 
> > Laszlo
> 
> 
> Basically OSes are tested on real hardware. Whatever firmware for
> real boards restores, OS-es won't restore so we have to.

For USB host controllers I'm sure this is the job of the OS.  At least
the linux kernel handles it just fine.  It'll figure whenever the uhci
controller lost power, if not it resumes the controller, otherwise it
does a full re-initialization and usb bus scan.  On qemu the later is
done as we do a full device reset on s3 resume.

xhci controllers have facilities to save/restore internal state to/from
ram, so the OS doesn't need to do a full bus rescan on resume even in
case the xhci controller is fully powered off.

cheers,
  Gerd