On Wed, 30 Jun 2010, Srdjan Todorovic wrote:
> On 29 June 2010 17:53, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
>
> > static struct pci_driver tg3_driver = {
> > .name = DRV_MODULE_NAME,
> > .id_table = tg3_pci_tbl,
> > .probe = tg3_init_one,
> > .remove = __devexit_p(tg3_remove_one),
> > .suspend = tg3_suspend,
> > .resume = tg3_resume
> > };
> > ...
> >
> > so, again, does the above make any sense if CONFIG_PM is not
> > selected during configuration? or perhaps i just don't understand PM,
> > suspend and resume well enough.
>
> Just occured to me - does tg3_suspend have the suspend code
> protected by the CONFIG_PM test?
there is no preprocessor test for CONFIG_PM anywhere in that source
file. and i think it's reasonably clear that there's nothing actually
*wrong* with including resume and suspend code in a module if there's
no power management, it's just useless in that it can never be
invoked, yes?
what i'm asking is if there's any rationale for including resume and
suspend code in a module when there's no power management configured
into the kernel. maybe there's actually some value to it. perhaps
the module might include an ioctl() call or something that allows
someone to *manually* suspend and resume a driver, i don't know, i'm
just trying to come up with possibilities.
or maybe all PCI drivers really should have all suspend and resume
functionality tucked inside of a CONFIG_PM test. is it really that
simple?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
