On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote: > On Mon, 14 Jan 2008, Bjorn Helgaas wrote: > > On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote: > > > ... And, now that I have your attention, while it's > > > not important to the issue anymore with the tests removed as the submitted > > > patch did, do you have an opinion on (include/linux/pnp.h): > > > > > > /* pnp driver flags */ > > > #define PNP_DRIVER_RES_DO_NOT_CHANGE 0x0001 /* do not change the state > > > of the device */ > > > #define PNP_DRIVER_RES_DISABLE 0x0003 /* ensure the device is > > > disabled */ > > > > > > I find DISABLE including DO_NOT_CHANGE rather unexpected... > > > > I don't know the history of those flags, but I wish they didn't exist. > > Ok, something to explain. These flags exists to allow drivers to > manually configure (override) PnP resources at init time - we know - for > example in ALSA - that some combinations simply does not work for all > soundcards. > > The DISABLE flags simply tells core PnP layer - driver will handle > resource allocation itself, don't do anything, just disable hw physically > and do not change (allocate) any resources. Value 0x03 is valid in this > semantics. It looks like sound drivers use PNP_DRIVER_RES_DISABLE to say "ignore what PNP tells us about resource usage and we'll just use the compiled- in or command-line-specified resources". The main reason to do that would be to work around BIOS defects or to work around deficiencies in the Linux PNP infrastructure (e.g., maybe we erroneously place another device on top of the sound card or something). I'm just suspicious because PNP_DRIVER_RES_DISABLE is only used in sound drivers. If it's to work around BIOS defects, why wouldn't other PNP drivers need it sometimes, too? And wouldn't it be better to use PNP quirks for BIOS workarounds? > Unfortunately, suspend / resume complicates things a bit, but PnP core can > handle DO_NOT_CHANGE flag. But it will just mean - _preserve_ resource > allocation from last suspend state for this device and enable hw > physically before calling resume() callback. When resuming, wouldn't we *always* want to preserve the resource allocation from the last suspend, regardless of whether PNP_DRIVER_RES_DO_NOT_CHANGE is specified? Linux PNP definitely has issues with suspend/resume, and I suspect this is one of them. Bjorn _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
