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

[Marcel Apfelbaum]

On Mon, 2014-01-13 at 09:58 +0100, Gerd Hoffmann wrote:
> 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 agree, I already sent a patch that does exactly that, I'll ping now.
Thanks,
Marcel

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