As Seb sort of implied in another case, quiesce() is also a required
interface, so it is expected that this project will also implement
this entry point, unless it provides equivilent information as would
be expected for non-support of DDI_SUSPEND/DDI_RESUME.
---- Randy
On Tue, 9 Dec 2008, Randy Fishel wrote:
>
> On Tue, 9 Dec 2008, Garrett D'Amore wrote:
>
> > Eric Sultan wrote:
> > > Garrett D'Amore wrote:
> > > > ...
> > > > 1) Would it make sense to support this on x86 hardware as well? (I'm
> > > > thinking server class headless systems, which I gather is the target
> > > > market for these chips.)
> > > It does make sense to support this on Solaris x86.
> > > >
> > > > 2) Does the driver support any power management features? (power(9e) or
> > > > DDI_SUSPEND?)
> > > The kernel device driver does not support chip-level power(9e)
> > > power-management, but does support display-level PM.
> > > I think, and will verify, that the driver does not support
> > > DDI_SUSPEND/DDI_RESUME.
> >
> > DDI_SUSPEND/RESUME would be helpful for some server class systems.
> > (Especially when we have useful Wake-On-LAN.) It might be worth
> > supporting,
> > but can be done as a bug fix/rfe.
> >
>
> Suspend/Resume is a core feature, and drivers are expected to
> support DDI_SUSPEND/DDI_RESUME, such that silence implies the project
> will implement them. So if this project does not intend to support
> this feature at initial integration, it needs to describe in the case
> why it will not and/or the plan for implementing them.
>
> Note: Magic Packet WOL does actually work when enabled by the BIOS,
> and the driver doesn't actually break it.
>
> ---- Randy
>
